(d) determining routii^ lequired to route the calk audio to a desired 
dcfdnidoQ, sak) routing detenninatkm baaed on the call data; 
and 

(e) oonfigurii^ laid matrix fwiicfa to route die call audio to aid 
desired desdnatkm determined in said stq> (d). 

21 . The method of cteim 20, further comprisiiv the Bteps of: 

(f) determinlmg whether ope i atof aisitisnpe is itt|uired to process 
the call, said determination based on the call data; 

(g) allocatiqg an operator oooaole to handle die call if operator 
asristanoe is required; 

(h) configuring said matrix switch to route the call awto to said 
allocated operator console so diat said operator assistance can 
be provided. 



22. The mediod of claim 20, wherein said step (e) comprises die 
steps of. 

(0 generadqg a switdi command message in said nmNxrk control 
processor, said switch command message based (Ni said roitfiqg 
dwrmined in said step (d); 

(g) sending saki switch command message to said matrix switch, 
wherein said switch command message configures said matrix 
switch to route the call audio to said desired desdnation. 
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23. The method of daim 21, wherein said step (h) oompriaes the 
steps of: 

i. generating a switch command message based on said 
roudi^ determined in said step (d); 

ii. sending said switch oonmiand message to said matrix 
switch to configure said matrix switch to tam the call 
audio to said altocaied operator console. 

24. The method of claim 21. further comprisii« die steps of: 

0) requestii^ information required to complete the call ftom the 



(i) receiving said required information at said allocated operator 
console and determinii^ whether the call can be completed; and 

(k) informii^ said network control processor whether the call can 
be completed. 

25. The method of claim 24, wherein said step (j) for determining 
whether die call can be compteted oompriaes die step of validatit« said 
received Informatkm to determine whedier said received informatkm is valid. 

26. The method of claim 25, wherrin said step of validating said 
information comprises the steps of^ 

(a) sending a validation request to a validation system, wherein 
said validation request includes infonnation to be validated; 
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2mu. 

-328- 

(b) letrievii^ valklation instnicdcmt fi^ 

validation imtnictioiu piovlde instnictioiii at to how the 
validation is pertbrmed; 

(c) execudt^ laid validation inttnicdons to validate nid 
infornutioo to be vaUdated: and 

(d) tending a validation response ID aid opeiaiorooniote Indicate 
whedier said information is validated. 

27. A mednd of providii^ opeiator assistanoe to a subscrter 
placing * telephone call, comprising die steps ofi 

(jO receiving a call ftoro the sulncriber, wheiem call data for the 
call is routed to a network control processor and call aiHfio for 
the callls routed to a matrix switch; 

(b) using siM call data to detemune the type of call placed and to 
determine whedier and what type of opeiator assistanoe Is 
reQuked^ 

(c) routing said call auifio to an opemor console allocated to 
provide operator assistanoe to the nibscriber, 

(c) requesting end reodving iitfonnation firmn said subscriber 
where required to con^lete d» call; 

(d) determining whedier die call can be completed t»ed on said 
call data and on said information; 
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(e) 
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J29- 

routiQg saM call audio to a lenninating number. 



28. A meUiod for provldiog enhanced call-processing fcaturw to a 
telephone subscriber, whereby die features can be accessed using an enhanced 
services card, comprising die steps of: 

(a) receiving an enhanced services card call firom die subscriber, 
wherein call data (or die call is routed to a network control 
processor and call audio Ibr die call is routed to a matrix 
swhch; 

(b) using said call data to determine dmt die call placed is an 
enhanced services card call, and to allocate an operetor console 
to handle said enhanced services card call 

(c) routing said call audio to sud allocated operator console; 

(d) lequesdiv and recdving infbrmadon from said subscriber 
regarding die feature said subscriber wishes id access; 

(e) roudqg said call audio to an appropriate destination based on 
dw feature accessed. 

29. The method of claim 28, wherein said step (d) comprises the 
steps of: 

i. receiving an enhanced services card number: 

ii. receiving a feature access number, and 

lit. receiving a terminatli^ number where required. 
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30. The method of claim 29, fiiftiier oomprinqg the ttep of allowing 
the subacriber id re-enter add received inf(»rmation diat Mied a validadon. 



of: 



31. A method for prooetaing tekephone calla, comprising the iieps 



(a) receiving a call from a subscriber having call data and call 
audio; 

(b) using said call data to detennine a process ami a DBF record 
to be used in procesring the call, wherein said process is 
defined by « process tctentifier and said OEF reooni is defined 
by a DBF reoocd idendfier, 

(c) sending nid piocess identifier and said DBF itowd identifier 
to an operate ccmisc^ alkcaied to handle said call; 

(d) starting said process identified by said process identifier; 

(e) netrieving data fiom said DEF record baaed on tag informadon 
contained in said process, wherein said retrieved data contains 
infornmtion pertaining to actions to be fbtkywed in handling the 
call; and 

(f) performing actions indicated by said retrieved data. 



32. A computer-based system for validating call information from 
an operator ocmsote, comprising: 
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a iHCode databue, oonfigurBd to store at least one validation instniction 
indicatiiv a mediod for performing a particular validation^ wherdn said 
method can be uniquely defined for each customer and each originating user; 
and 

a validator configured to receive die call information to be validated 
from an operator console, to retrieve said at least one validation instruction 
from said p-code datidiaae» and to validate die call informadon using said 
method indicated by said validadon imtruction. 

33. A computer-based sy^em for updating a first set of at least one 
dattbase to reflect changes made to a second set of at least one database, 
oonq>rising: 

a delta table, fior storing changes made to said second set of at least one 
database; 

at least one trigger, configured to capture said changes made to said 
second database and to store said changes in said delta table; and 

a distHbutor, configured to iqxiate appropriate ones of said first set of 
at least one database using said duuiges in said delta tsble whereby said first 
set of at least one database reflects changes made to said second set of at least 
one database. 



34. A system for providing a calling party witfi a ntte quote for a 
telqrfione call, oomprismg: 
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a mte file, configured to store MlliiQ cm fior tdqihoDe calls, wherein 
said ntes are stored based on call attrflrates such u time of day, juHsdicdoo 
of call, identification of customer, and lype of call; and 

an opetator console, configured to communicate with the calliog party, 
to retrieve a billing rate Iter a telephone call ftom said rate file, and to provide 
a rate quote to die calling party for die telqihone call. 

35. A client/server inter&ce system oomprisiQg: 
a dient interfisoe; 

a oonfiguradon fite coupled to said dient intertee; 

a dmer ooupM to said diem inlBrfooe; 

an outstanding request list coupled to said diem intertee; and 

an incomii^ packet list coupled to asid diem intertee. 

36. A system for deiBCtii\g fnudulem use of a tetephone network, 
oomprisiiQ: 

a billed number usage module configured to receWe call information 
pertainli^ to tdl calls placed over the network, to store said reodved call 
information, to compare said reodved call Information with an established daia 
boundary, and to genersie an alarm signal when said data is outside said 
esiablidKd boundary; 

a Wled number usage noodule. configured to recdve fiuled call attenqH 
information, to analy» said reodved hikd cdl attempt information, and to 
maintain a historicd feccmi of Mled cdl attempts; and 
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m fnud coniole, coupled to siid billed number usage module and to 
said bilod number usa^e module, configured to receive said alarm signal, to 
alert a system operator of the occunrtnoe of an alarm signal, and to display 
received, stored, and alarm information. 
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Abitmct 

A sysfiem and method far precestiog tdqihone calls and providing 
enhanced services is presented. The call processing system includes a network 
control processor for oourolling the processing and rousing of the calls and for 
providing enhanced features, and a matrix switch for routing calls from an 
originatii^ locailan to a terminatiqg location. Operator oonscdes can be 
included to provide opeiator assistance to die caller. The netwoilc control 
processor comprises a central message processor that receives call data* 
determines the xypt of call, determines die processiiv required, and determines 
whedier opeiator assistance is required. A call route distributor allocttes an 
operator console to die call if required. A bUliitg server is used to track 
billing hifonnation for the call while it is in progress. A database server is 
provided for database knkHips and storage. The call procesBRg system also 
includes a validation tywsm, a billing ^stem, a distribution system, and a 
fraud detection and prevention system. The validation system is used to 
validate call information to determine whedser die call can be placed. The 
billing ^stcm detenmines rates for calls and calculates die cost of completed 
calls. The distribution system distributes changes diat are made to a master 
database to die appropriate slave database. The fraud detection and prevention 
sy»em moniton originating ard iniiiQoess calto 10 detect and posnbly prevem 
possible firtiidulem uses of phone services and systems. A client imerfoce ts 
provided to teititate communications among oplications and DEF records are 
used to define specific call prooesnng atikms. 
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BaO^md of Am bmntlon 

IS i. FIM^a^imtmi^ 

The present invemioa relates geneially to systems and 
piooessing telephone calls, and more particularly, to systems and methods for 
allowiiv telephone carriers to offer enhanced products and services to dieir 
suhscnbers. 

20 2. ROaMM 

Dei^ulation of the long-distance telephone industry spawned the 
growdi of numerous loi^-distance service providers, each vying for a share 
of die UnitBd States' loiig-distanoe maiket Thus for, dw U.S. industry is 
dominated by three huge companies: AT&T, MCI and S|»int These large 
25 carriers have the resources and capital at dieir disposal to enable them to 

develop and provide a wide range of telephone-related services to their 
customers. 

Perhaps less known, but sdllextrenttly Important in die more than $50 
billion imerexchaiige U.S. loqg-distanoe market, are die smaller companies. 
30 In 1991. AT&T, MCI and Sprint controlled approximately 85 percent of the 



U.S. niufcet. At ihU time, 12 nie(fiiim-4i»l ooniptidei 

of the U.S. maiket The itmainiQg leven penem of ihe U.S. mufcet was 

divided imof« nearly 320 small csrriers. 

The Uiier carrien aie able to amact customen by offe 
of services in addition to direct dial calling. These services include, but are 
not limited to: opemtorwisied callli^, full-feature calling cardSp and 
spedaliaed 800 muriber roudpg. 

The stnl^ followed by die smaller carrien in attrMing customers 
has been to offer exoeltem service and low-oost, dlnct-dial hn^islanoe 
calling (e.g. 1 + calling). Many smaller carrfers, for eaamfile. fecus on a 
particular geographic marlcet. By understanding die market's calling pattems, 
the smaller carrier can maximize crucial economies and can attract nibscr^iers 
by offering long-distance calling st mes lower than diose offered by larger 
carriers. 

Additimlly, many smalls carrters use die feet tint diey are a small, 
kical business in order to attnuxodier local burineases as didr clients. These 
carrfen stress die ability to offer more personalind. responsive attention dian 
some larger carrim may provide. 

However, many of the smaller carriers are finding it increasingly 
difficult to compete widi die larger carriera by offering direct-dial callirug 
alone. Forthesecarrierstoattrsctandteiaincustomera, they need die aUliqf 
to offinr die same rai^ of features and services provided by some of the brg^ 
carriera. For example, a small carrim may Imve a small trsvd ngcncy as a 
long-distance subscriber. As die travel agency grows, develops more 
business, end hires additional salespersons, die travel 9gieacy"s telephone 
services leqwremems also grow. Thetravelagency may want to offer calling 
cards to its salespersons who travel frequendy. The travel agency may also 



1462.0010000 



2116462 

•3- 

warn tfte abili^ to re-route an inooming call that was made to their 800 
number. Such re-nmting allows the travel agency id re-ioute incoming 800- 
number calls to any telephone number, a voice mailboK, or a pag^r. 
Additionally, the travel agency may want the ability for its office workers, 
clients and vendors to make opeiator^assisted calls. 

Unfimrtunately, most smaller carriers can only provkle direct-<iial long 
distance service to its customers. If a smaller carrier warns to offer eithanced 
products to its customers, the smaller carrier has two chdces. First, the 
smaller carrier may puiduue its own telqrtione switchiqg system and operator 
conac^ Second, the smaller carrier may purchase and resell the productt of 
one of its larger compedlors. 

However, reliable, affordable, and scalable switdiiqg equipment Is not 
commendally available. If a kmg^istanoe carrier wants lo purchase its own 
equipn»nt, the selection is limited to the large-scale complex switching 
systems dwt are currently available. Because these systems are costly, in most 
instances, the smaller carrier is forced to go through a larger carrier to obtain 
enhanced products. 

Several problems arise out of the inability of smaller carriers to provide 
enhanced calling services, f^r of diese problems are now described. 

First, the flexibility and customization options available to the smaller 
carriers in providing services are limited when diey resell die products of their 
larger competiiDr&. One reason for diis is that those products were not 
designed with the mailer carriers' needs in mind. For example, consider a 
smaller carrier that wants to offer a product like 800 number forwarding to its 
customers. The smaller carrier will want iu customors to hear customized 
user prompts. Including the idendfication of die carrier. The smaller carrier 
will also want to establish its own prices for die service. To further customize 
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its systems, the carrier may want to change the way the call prooesaes, or to 
add additional features such as the ability to loute an 800 number to a voice 
nudlbox. 

In anotfier example, the smaller carrier is unable to provide carrier- 
unique opmtor services. The cost of providing opeivtor services prohibits 
most mailer carriers from hiriiig dieir own operators and puichasiiig the 
required equipmem. Instead, smaller carriers typically purchase operator 
services from a conq)etiior carrier or from operator service providen. 

One drawback of having to use a conqiedtor^s openton is the inabili^ 
to cuatmn brand die call. For exampk, when a customer of die nnaller 
carrier places an openlor^sted call MAog a oomp^tor carrier's operaion, 
she hean the operator of tht competitor carrier duuik her for uniig the 
competitor carrier's services. 

Anodier drawback of having to use anodier*s operatora is die inability 
to custonKailor call processing because die operator servkses provuled and the 
operator responses cannot be customised. The smaller carrier las no control 
over die operatora used by die competitor carrier or die operator servkx 
provider. 

Relying on larger carriera for providing diese eidumced products does 
not give smaller carriera die flexibility diey desire. This is because smaller 
carriera cannot customi» die products diey obtain from die laiger carriera to 
provide unique services to didr subscriben. 

A second problem is die range of services diat can be provif*^ by a 
smaller carrier is limited to die servwes diat carrier can purchase from its 
compedtora. As a result^ die smaller carrier often cannot create innovative 
new products and services to offer its customers. 
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An addhkxal problem is that the amount of fraudulent calling 
conrideied aooeplable. and iherefmt ncx monitoied or halted by a laiger 
carrier, may be well above a level that is economically toleiable for the 
smaller carrier. 

Another problem is die smaller carrier's inability to get customiied 
fulfillment material dirough a competittw carrier. For example, calling cards 
provided by a larger compedtor carrier, in turn lo be provided to die smalter 
carriefs customers, often bear die name of die compedtor carrier. 

In summary, because die small carrien must rely on die larger 
compedtor carriers for advanced products and services such u calling cards, 
operator asdstanoe, 800 service, audiotext, voice nmll, and die like, the 
smaller carrien cannot offer a fUll range of carrierninique and outomer- 
unique products. As a result, die smaller carrien lose part of dieir ability to 
compete in the U.S. long-distance marlcct. 

The problems of flexible control of a telephone networic are not limited 
to die smaller carrien or die long-<listanoe industry. All telephone carrien 
would benefit from die ability to offer popuhur, cusfeomiwi, value-added 
services. Commercially avaihd>le hardware and conventional solutions to date, 
however, do not offer diis ability. 
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Summary of the Invention 

The present invention is directed to a call procesung system and 
method which provides a wide range of enhanced calling products and features 
to subscribers. The subscribers can include individual users as well as 
customers who, in turn, provide telephone service to their own clients (also 
called "users"). These customers can include telephone carriers whose clients 
are subscribers of the carriers* network and can also include odier types of 
businesses. 

The call processing system is implemented in such a way diat 
customer-unique and user-unique customised products and features can be 
provided. The features, products and services provided can be extensively 
customized to provide system flexibility and lo offer users the option of 
choosing the level and types of features, products and services diey receive. 
Customization can also be provided at the business- or carrier-customer level 
so that these customers can choose the level and types of features, products 
and services they wish to make available to their clients. 

The call processing system includes at least one network control 
processor (NCP) and at least one switch (for example, a matrix switch). The 
network control processor (NCP) is a unique combination of hardware and 
software configured to determine the type of call being placed, the type of 
handling to be provided to the call, and to control the routing of die call. 
Because the NCP makes call handling and routing determinations regarding 
each call received, the switch implemented can be a passive switch that simply 
responds to routing instructions received from die NCP. Thus, control of die 
call is maintained by the NCP. 
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Onefeatore of the invention b that it provh^ 
a call Is provided to the NCP to enable the NCP to make call processing 
deienninattoas. The call data can include infimnation luch as die originating 
(caller's) phone number (die ANI), the called phone nuinber, originating and 
terminating area codes, customer identiflcadcm codes, and otfier like 
information. The NCP uses dds call data to make determinations regarding 
die manner in which each individual call is to be handled and to instruct die 
swHch cm how to route the call. 

Acocmfing to this irtiikMphy, only die audio portion of die call is 
routed to die switdi. The call data is not routed lo the switch. Therefbre, all 
call processing and handling determinations are matte by die NCP and die 
switch can lie impteimnted as a passive device. 

The call processing system can also include one or more operator 
consoles to provide operator assistance to callers. The operator consoles 
provided can be manual operator consoles (M (K^s) staffed by human operators 
to provide a human operator interhoe to calters. Alternately die operator 
consoles can be automated voice response units (VRUs) dnu provide automated 
assistance to callers. Additionally, a customer service console (CSC) can be 
used to provide detailed customer assistance to subscribers. 

When a call is received by die call processing system, die call data is 
routed 10 die NCP and die call audio to die switch. The NCP begins handling 
die call white die audio circuit is held at die switch. Hie NCP first aarigns a 
callhandte to die call; dds is a unique tdendfier diat can be used to identify 
bodi die call and call handling operations perfbmed in conjunction vrith the 
call. 

Once a callhandte is assigned, die NCP determines die type of handling 
and/or processing die call requires. In one erobodimem, dds is accomplished 
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by retrieving ctll panmetm for the call. The cill puvneteii indicne the 
type of call being placed, wheth^ and what lype of apmsoc aarinance la 
recfuired, and other pnioeastng lequlred for the odl. The call pammeien are 
contained in a data record that it retrieved baaed on the call data. The NCP 
uies die call data for eadi call to look up a data leooid diat containa die call 
pvmmeters for that call. Becauie different data records can be maintained for 
difiierem comUnatkmi of call data, umque or cuatom call handling and/or 
processing can be defined down to the customer and/or uso* level. 

The call parameters include inforroadon on how the call is to be 
processed in die call processing system. The call parsmeien include what are 
termed a "DBF Record Number" and a 'Base Proceu Number" that point H} 
a series ofdata records chained togedier to define die call processing required 
for die call. These records are termed "DBF Records." DEP records are 
described In more detail bekiw. 

The call parameters also include infortnation regardii^ whedier 
operator assistance is required to handle the call. If opersior assistance ii 
required, call parameters include a device type list dat indicates die type of 
operator assistance required. This list can specify «1iedier a MOC, VRU, or 
CSC can be used to handle die call. Because call parimefien can be uniqu^ 
defined for each customer and/or user, die operator services provided can be 
customiied down to die same level, if desired. Thus, a particular caller can 
be defined as always recdvingopenuor assistance fhmi a hwnan operator, or 
a pardcular call type (such as a calling card call) can ahMys be designated to 
receive automated VRU Imndling imdally. The device type list can also 
indicate diat a less complex device, sudi as a recorded message playback 
device is required. 

Call param^crs can provide fiirdw specificity in the type of Qperaior 
assistance required. For example, die call parameters can include a language 
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type diat indiaiM ptiliculiF call requires openuor asiistuice In a ^lecific 
lai«ui«e. When the N€P retrieves call panmeten that indicalB a specific 
lai^uage is required, the call is routed to an opentor console tliat can provide 
assittanoe In tint language. For example, when a call is received from a 
specific originating mimber, the call parameten retrieved for that number may 
indicate diat Spanish-language operator assistance is destred. Again, as witfi 
die other call parameters, the determination is made based on call data 
assodated with the call. Thus, die language provided to handle each call can 
be customized at the user and/or customer level. 

If operator assistance is required, die NCP allocates an openuor 
console to handle the call. The allocation is made baaed on the call 
parameters retrieved for die call. Fat example, if a device type list Indicates 
that a MOC is desired, the call is routed to an avaitable MOC. If no MOC 
is currendy available, the call can be placed on a queue. Music and/or odier 
messages can be provided to die caller while die call is queued. A status 
display provides a visual Indication of the number of calls In the queue. 

So that the correct device type can be allocated to handle a given call, 
die NCP maintains a list of consoles available to handle calls and diose 
consoles cunenUy handling calls. The list can include infomadon about eadi 
console pertaining to die type of console, die languages diat console can 
support, and odier pertinent infornutkm. Thus, if a Frmb-speakiqg human 
operator is required, die NCP checks dw list to see if a MOC widi a French* 
speaking eperalor is cunendy av»labfe. If availaMe, dot console is alkxated 
to handle die call. If unavaihdile, die call is queued. 

Once a oomole is allocated to handle a call, die NCP instructs die 
switch to route die call audio to die allocaied console. Because die switch is 
routing only die call audio (and is not handling call data), die consoles can be 
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tieaced as any other (erminadiv point cm the twitch. Thus specific, or 
dedicated, operator console ports are not required on the switch. 

The NCP also sends operator control data to the altocaied opcralor 
console, Infbrmii^ the allocated consde that a call is heing routed to it 
Included with the operator control data ii the base process number, a DBF 
record number and other call information from the call data. 

When the call audio is touted lo the operator console, the operator 
requesuinfornnatlon from the caller. A script is displayed on a screen on the 
openiior console for the human operator to read. For an automated VRU, the 
script is a recorded or synthesized voice that prompts the caller for 
information. The particular script to be read or pbiytd is retrieved from a 
database by the operstor console when prooessii^ the call. One manner in 
whidi tfils can be accomplished is through the use DEF records as 
discussed below. 

The caller responds with the requested infiDrmatlon. This information 
could be v^lly provided to a human operator, who then enters it into the 
system via the operator console, or could be a sequence of one or more keys 
pressed on the telephone keypad. The informadon requested of die caller can 
include: die number to be called (if not originally enimd on a 0- call); billing 
information such as a calling card mimber, enlnnoed services card nunter, 
credit card number, ddrit card number, or tetephone mmta' to be billed; a 
feaftire idendiicatlon (for exanq^le 21 fbr speed-dial); a security code; and 
odier like information. 

The infomotion entered is validated to ensure dttt it is correct and diat 
die call can be completed. One mediod of perfiamiing validations is to do an 
internal validation. For example, the called number is validated to ensure dot 
it b die correct number of di^ts or terminatii^ number is validated to ensure 
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that the call is being placed to an area that is within that caller*s allowed 
calling area (if restricted). 

Alternatively, a validation system, which is part of the call processing 
system, could be used to validate other information required to complete the 
call* Billing information can be validated to ensure that the method of billing 
is acceptable. Credit card numbers can be checked through validation service 
providers and debit cards can be checked to determine whether the balance is 
sufficient to place the call. Security codes can be checked against the feature 
to be accessed, the originating number, die billing information, or other 
parameters screened through the use of the security codes. 

If the information entered is invalid, die caller may be given a second 
chance to re-enter the correct information, or alternatively, the call may be 
terminated. If the call is being handled by a VRU, the VRU may transfer the 
call to a human operator to provide additional assistance. The number of 
chances provided to a caller who enters incorrect information, whether and 
when the call is transferred to a human operator, and when the call is 
terminated due to invalid information is customizable to the customer and user, 
as parameters in the DEF record. 

If the information is valid, the operator console sends data to the NCP 
indicating that the call can be routed to the terminating (called) number. The 
NCP performs a number translation, where required, to determine the proper 
routing for the call. Once the routing is determined, the NCP generates 
instructions to command die switch to route the call to the destination. In one 
embodiment, the switch instructions are packetized for transmission via a 
LAN. A gateway removes the instructions from die LAN packet(s) and 
formats them into a form that is recognized by the switch (SS#7). The NCP 
also releases die operator console from the call so that it is free to handle 
another call. 
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The switch rnMbs the call to the destination via a telephone network 
baaed on die instructions received from die NCP. Standard telephony 
signalling can be used to con^lete die call to die called number. This includes 
call accept messages (for example, ACMs) and answer messages (for example, 
ANMs). 

If die call does not require operaior asnstanoe, die operator alloGation 
steps and die opoatarhandllr^ steps described above can be bypassed. Indris 
caae, the called number can be validated to determine whedief the call can be 
completed. This can include validations to determine whdfaer the call is to an 
acceptable calling area and whedier die called number contains the correct 
number of digits. 

The validation system can be used to validate billiiw information, and 
informadon l.e., whedier a credit card nuniber is valid for credit card calls. 

When an operator console wishes to validate call informatiOT prior to 
die compledmi of a call, it sends a validadon request to die valuation system. 
The validation request includes an index and call data or odier information to 
be validated. When die validadon system receives the request to perform a 
validadon, it retrieves validadon instnicdons, termed "p-code,** from a 
database. These instrucdons contain die process to be followed in validadng 
die infiorroadon. In one embodtmem, die index provided widi die validadon 
request indicates die apedfic p-code instrucdon to r^rieve for dmt validation. 
The operator console requeuing die validation determines die index and 
provides it widi die request In one embodiment, die Index is defined based 
on die call type. Thus, for each call of die same type (i.e. fbr each calling 
card call, or fbr each credit card call, etc.), die index pdnts to die sai le n- 
code instrucdon. In altemadve embodiments, die index can be uniquely 
defined at die user and/or customer level to customize die vdidadon process 
at diis level. 
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The retrieved p-oode insmicdon piovidet infimnatioii to the valkfauion 
aystem regudi^g validation of the call. For eumpfet the p^code iminictlaiis 
may tdl the validation syuem diat it must fint look for die orjgiiiatini miioAer 
(ANl) in a hot/odid database. If die number appean ai a iBot" numbo', die 
validation ftih and the call riuuld not be contpleted for diat number. An 
example of when this oocun it when an originating number it uied to place 
fiaudulent calls. This number can be put in die hot fite to stop toH caUs ftom 
being placed fkom duu number. If die muiiber appears as a "ooU" number, 
diat call is to be oompletedwidiout further validadon. This could be used fbr 
calls originadqg ftom a number where dme is of die essence. 

The p-oode may then instruct die validation system to validase die call 
against a validadon index file. In dris validadon step, die call data (for 
example called number, c^nadng number, originadng area code, ecc) ts 
validated against various parameters to determine whedier die call should be 
IS blocked. Ifdie call is blocked, a response is sent to die ocmsoleindicatii^ diat 

the call cannot be oompleted. 

The p-<ode nuy also instnict die valkladoa system to perform an 
external validadon. One example of where diis is useful is where a credit card 
nuinber is tt> be validated via an extennl credit card valfclatkm service. Inthis 
20 stqi, die outside source is ointacted via inodem or odierdaiatink and p^^ 

widi die informadon to be validated. The outside source perfanns the 
valuation and responds widi a positive or negative re^Kme. If die 
infbnnation is invalid, a response is sent to the console indicatiiig that die call 
cannot be oon^ileted. 

25 A key feature provided by diis architecture is dukt dmagies to die 

validation process can be made qmddy and easily by nrq^y updating |M»de 
in die database. Operational code of die validation ^stem does not have to 
be recompiled to implement changes to die validation process. 



€ 



S 



10 



1462.0010000 



2116^62 



- 14- 

The call prooessiqg system also can include a billing system for 
delenniiung Ihe lates for calls and services, demmining the costs for calls and 
services, and for genuitf ng bills to bill subscribers of die call processini 
system. The bllllog system Includes a rstiag system, a rate file, and a toil file. 

The billing system can provide rato quotes for a call that tell the 
requestor how nnich a call will cost This feature can also be used by the call 
processiiv system to determine v^ien the dollar amount lefk on a user's debit 
card is goii« ID be depleted. In one embodiment, when a user places a debit 
card call, the operattyr console ttquests a nte quote from the billing sysmn. 
The billing system looks uptherateforthecallinlheratB file. The rate can 
be based on the time of day, the distance overnMch the call Is placed and the 
pardcutar customer or user placing the call. 

The billing system provides the quote to die operatKHT console and to die 
NCP. The NCP fttrievei information Indicadng tfie remaining dollar amount 
on die credit card. The NCP then computes the amount of dme diat Is 
remaining on the card based on the rate quote for die call and the remaining 
dollar amount When the remainii^ dme is about to expire, the user is 
provided widi a warning indicating how much dme is left. When die dme 
expires, the call can be terminated or the user given options to replenish die 
debit card. 

When a call is received by the call processing system for routing, a 
billing infionradon record (BIR) is generated for the call. Among odier 
infbrmadon, the BIR is iqidsted wtdi timing infonrntdon such as when die call 
is completed to a VRU or to an operator console or when it is terminated. 
When die call is completed, die BIR Is sent to die billing system so die cost 
of die call can be calculated. The billing system uses die time information to 
compute wholesale and retail call durations. The billing system uses odier 
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infonnatioa oontuned in or derived from the BIR tuch u due of day and 
distance of the call to letrieve a rale for die call. The billiqg fytten 
cafculaM a cost fbr die call (wholesak and/or retail) un^ 
and the call duration. If itquired, a tax for die call is computed and added k> 
die cost of die call. The cost information is stored in a toll file fiom ^i^iich 
byis can be genented and sent to die qiprapriate subscriber. 

Aocofdiiig to one embodiment of the present invention, call praoessiiig 
Is performed u^og what are known as DBF teootds. Tlie call parameiers 
determined by die NCP when a call is received include Information pertaining 
to a DBF record and a base process for prooessiQg die call. This informatiim 
is provided to die operator oonsc^ in the form of a base procea number and 
a DBF record number. In processiqg die call, die operator console starts die 
base process idendfied by die NCP. The base process is die basic process ditt 
is to be followed by die opeiatiMr console in handliiv die caU. It can include 
die ba^ steps to be followed by die operator console and can be coded to 
look for spedfic data (ideiidfied by tag nuirtiers) in a DBF record, reqp^ 
certain types of information contained wldiin die DBF record, or wait for and 
respond to information received firmn die caller. 

The base process is started by die opemfor oonst^ The base process 
indicates dw data (using tag numbers) to be retrieved lirom die id^ 
record, and die ortier In wUdi it is to be retrieved. TMs dam contslns 
Infonnadon regarding steps to be perfofmed in processing the call. Thedata 
may indicate that certain scripts are to be played (or syndiesiwi or read) to 
die caller, dutt certain validations are to be per for med, or odier processes 
started. The data may also indicate die acdonsdnt are to be taken in response 
to key entries made by die caller. When die base process is finished, it runs 
a finish process. The finish process may poim to anodier process to be run 
or it nuy po^m to a complete process used to con^lete the call. 
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BecMiae call piooesiing isoonmrftod using dam rooonta, one advamage 
of uung DBF reoonb is lhat changes to the manner In wl^ calls are 
processed can be iraplementod by changiiv the data in the datt lecoi^ An 
* addttkmal advantage is diat call processing can be customiied for a spedfk 
user or customer. Because die particular DBF record chosen for call 
processing Oiutially) is selected based <hi call data, changes to the DBF record 
adected can result in change to die way the call is processed. Thus, one 
DBF record may indicate diat a certain script is to be played or diat certain 
information is to be validated or diat key sequences input by a user are to be 
responded to in a certidn way. Odter DBF records may Indicate odier 
operations to perform or odier ways to respond to user input when processing 
a call. Thus, it is die DBF record diat defines how a call is to be handled. 

Changes to the data In databases of die call processing system can be 
made using a distribution system. For redundancy, certain databases are 
mirrored to provide a high degree of tailt tolerance. To maintain integrity of 
all databases, changes to any of the master databases must be made to all 
affected slave databasM as well. To acoompUsh this, die call processing 
system uses a distribution system, which captures the changes made to tables 
in the master database and updates die affected slave databases widi these 
changes. 

A trigger captures changes made to the master database and stores 
diese changes in a delta table. A distribution server retrieves diese changes 
and creates a net messi^ table indicating die changes to be made and an audit 
tabfe indicating die slave databases affected by each change. The distribution 
system dien updates die affected slave databases using die messages in die net 
message table. 

One advantage of die distribution system Is diat triggers are used to 
simplify the operations performed and to ensure the integrity of slave 
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databaaes thnx^gbout the entire call prooessiag lysiem. A trigger ia called 
each time a change is made to die ma^ database. The distribution system 
is tFBnaparent to die application makii^ changes to master database. The 
application making die chai^ to master database is not invdved with die 
process of modifying the slave databases with the same changes. 

The use of a delta table isanottier advaittageof the distribution system. 
Through the use of die delta table, only die data dot is needed to update slave 
databases ia provided to die distributxH*. The chai^ are dien read from die 
delta table to be applied to die an>ropriate slave daodnses. Tb's mediod 
allows die application performiiig die change to die master database lo 
continue pertbrmiitg any odier activities required, while die distribution symrn 
makes die diai^es to die appropriate sfaive datdnses. 

Still anodter advantage of dm distributkin system is that U does not 
require diat updates to all databases be timultaneous. This feamre allows 
slave databases lo be updated at dieir own pace. If any one of die affieclBd 
slave databases is down, die changes are queued until diat database is ready 
to receive them. 

The call processing system can also provide real-time momtmng, 
detection, and prevention of fraudulem uses of the system. This iunctionali^ 
is provided by a fraud system. The fraud system handles and detects fraud in 
bodi calls diat successfully complete (go dirongh), and calls diat fail. The 
firaiMl system is an integrated system dut monitors manual operate consoles, 
automated VRU conscrfes, as well as die NCP and die billing system. Spedfic 
fraud consoles are provided to fraud administnuors assigned to die task of 
fraud detection and prevention. These individuals can monitor die operation 
of any call in die system in real time and can take any necessary actions for 
fraud detection and prevention. Automatic database storage of critical data 
associated widi detection and prevention is provided. Alarm levels can be set 
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so that when dtia exceeds specified limits, an alann ii triggered to a fraud 
administiatior. The architecture of the system allows for spedfic frawl 
scenarios to be detected and prevented. The present invention is robust 
enough to accommodate additional fraud scenarios in the fbture. 

Further features and advantages of the present inventicm, as well as the 
structure and operation of various embodiments of the presem invention, are 
described in detdl below with reference to the accompanying drawings. 
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Brief Description ofihe Drawings 

The present invention is described herein with reference to the 
accompanying drawings. In the drawings, like reference numbers indicate 
identical or functionally similar elements. Additionally, the first three 
characters of each reference number identifies the drawing in which the 
reference number first appears as per the table attached to the document as 
Appendix 1. 

Fig. 1 is a high-level block diagram illustrating the architecture of a 
conventional telephone switching configuration. 

Fig. 2 is a high-level operational flow diagram illustrating die manner 
in which a conventional long-distance carrier provides long-distance telephone 
services to a loiig-distance carrier customer. 

Fig. 3 is a high-level block diagram illustrating a call processing 
system according to the present invention. 

Fig. 4 is a high-level block diagram illustrating the interface of 
customers and users to the call processing system according to one 
embodiment of die present invention. 

Fig. 5 is a high-level operational flow diagram illustrating die stq>s 
involved in placing and completing a call using die call processing system 
according to one embodiment of the present invention. 

Fig. 6, which comprises Rgs. 7 and 8, is a high-level operational flow 
diagram illustrating die process that the call processing system uses to process 
operator-assisted calls according to one embodiment of the invention. 
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Fig. 7 is a higlhtevel operadona] flow diasnm inusoidng the process 
that the call the processing system uses to prooen operator-assisted calls 
according to one entediment of the invendon. 

Fig. 8, which is a condnuation of Fig. 7, illustrates a high-level 
opeiadonal Bow of Ae process duit the call prooesslQg ^ydem uses to process 
opentOT-assisted calls aooording to one embodiment of die imfendon. 

Fig. 9 Is a high-level block diagram ilhistredog a representative 
architecture of one embodiment of die call processing system aooording to die 
present invention. 

Fig. 10 is a block diagram illustrating a high-level architecture of die 
netwoik control processor according to one embodiment of die invendon. 

Fig. 11, which comprises Figs. 12 and 13, is an operalional flow 
diagram illustrating die steps followed by die netwoik call processor in 
handling a call requiring operator assistance according to one embodiment of 
die invention. 

Fig. 12 is an operational flow diagram illustrating die sie|m followed 
by die network call processor in handling a call requlriiQ operstor assistance 
according to one embodimem of die invention. 

Fig. 13, which is a continuation of Pig. 12, is an operational flow 
diagram diat illnstrstes die steps invdved in handling die call requiring 
operator asristanoe according to one endiodlmeni of die invention. 

Fig. 14 is a data flow diagram illustrating die data flows diat occur 
widiin and external to die network control processor when a call requiring 
q>erator asnstanoe is received according to one embodiment of the invention. 
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Eg, 1S« which oomprises F^gt. 16 and 17, ti a data flow diliiam 
illustnti^g the data flowt that occur within and external to the netwoik contral 
processor when a calliqg card, credit caid, or debh caid call is oonqitod 
aooofding to one embodinmit. 

Ptg. 16 is a data flow diagram illuAiatiqg die data flows diat occur 
widiin and external to die network control processor when a caOiog can!, 
credit card, or debit card call is oon^letBd aoconUog to one embodimem. 

Fig. 17, which is a condnuation of Fig. 16, illustrates die data flows 
that occur whhin and external to the network control processor when a caUiqg 
card, credit card, or debit card call is oompleied aooordiiig to one 
emboitinienL 

Fig. 18 is an operadonal fkiw diagram ilhistradiig die operadon of 
completiiQ a calling card, debit card, or credit card call aooording to one 
embodiment. 

Fig. 19, which comprises Figs. 20 and 21, is a dataflow diagram 
illustratit^ die dataflows diat occur widiin and external to die netwoik control 
processor when a collect call is cotnpleied. 

Fig. 20 is a dataflow diagram illustrstiqg the dataflows dmt occur 
widiin and external to the netwmk control processor when a collect call is 
oompleiBd according to one embodiment of die invendon. 

Fig. 21, which is a oondnuatkm of Rg, 20, illustiates the dataflows 
diat occur widiin and external to die network control processor when a collect 
call Is completed aocordiog to one embodimem of die inventkm. 
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Fig. 22 IB an apendonal flow diagram illustnuing the operatioii of 
completing a collect call acoonKng to one embodiment of the inventkm. 

F^. 23 is a high-level opeiatioial flow diagram illustrating the manner 
by which call processing system provides language^specific operator services 
according to one embodimem of the invention. 

Fig. 24 is a Mode diagram ilhistnoing a call route distributor and its 
interftoes acconling to one embodiment of the invendon. 

Ftg. 2S is a high-level block diagram illustrating primary and 
secondary call route distributon and titeir Inierbce to operator consoles 
sccording to one enibodiment of the invention. 

Pig. 26 is an operational flow diagram illustrating die process by which 
call route distributors determine which call route <Hstributor is primary, and 
die process by which operator consoles tog on to the primary call route 
distributor according to one embodimem of die invention. 

Fig. 27 iialugli-level operational flow diagram illustrating whatoocun 
when a call is received from a subscriber by die call processing system 
acconling to one embodiment of die invention. 

Ftg. 28 is a block diagram illustrating an example architecture of a 
central message processor of die NCP and its interfiboes to external processes 
aooordii^ to one embodimem of the inventton. 

Fig. 29 is a message flow diagram illustrating die flow of messages 
between the cemnJ message processor and die odier processes widiin die 
network control processor according to one embodiment of the invention. 
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Rg. 30. wMch oompriaes Figs. 31 and 32, Is m opmtional flow 
diagmm illusttating the opentions pcrfonnc d by the oemnl memge prooeoor 
in sending and receiving the messaget illusmued in Fig. 29 aooonliog to one 
embodiniem of the invendon. 

Fig. 31 Is an operational flow diagiam illiutnting the opeiatiafu 
performed by the oential message prooesior in sending and nodving the 
messages illustrated in Pig. 29 accoiding to one embodiment of the inventioo. 

Fig. 32, which is a oominiiation of F^g. 31, is an operational flow 
diagram illustnuiiig die opemttons performed by die central message prooesaor 
in sending and receiving the messages iliustnted in Fig. 29 aooonUng to one 
embodiment of the invemkm. 

Fig. 33 isadiagnun illustiating an example acdoo record aoooiding to 
one embodiment of die inventkm. 

Fig. 34, which comprises 35 and 36, is an opeiational flow 
diagrsm illustrating the nnnner by whidi a message manager of die cental 
message paooessor uses action records to process a network request aooofding 
to one embodimem of die invention. 

Fxg. 35 is an operational flow dntgram ilhistratir« die manner by which 
die message nanager of die centra] message processor uses action reooids to 
process a network request acoordti^ to one embodiment of die invention. 

Fig. 36, whkfa is a oontimitation of Fig, 3S, is an opentional flow 
diagram illustrating die manner by which die message manager of the central 
message pniceasor uses action records to process a network request according 
to one embodimem of die invention. 
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Ftg. 37toanoperatk>rolflowdii«graminui^ 
calb that do not require opeittor asnstanoe ire completed tocoiding to one 
enibodlmeiit of the invenfon. 

Fig. 38. which comprises Figs. 39 and 40. is an opeiational flow 
diagram illustntiag the manner in which die oentnl message processor 
releases a call ftom an operator console accoidiqg to one embodiment of the 
invendon. 

I^. 39 is an openuiona] flow diagram illustndag dw manner in which 
d» central message processor releases a call from an operator ccmsole 
aoamiiag to one embodiment of die Invemtcm. 

Fig. 40. which is a condnuation of Fig. 39. is an operational flow 
diagram illuatiidng the mumer in which die central message processor 
refeases a call from an operator oonsrie according to one embodiment of die 
invention. 

Rg. 41. which comprises Figs. 42 dirough 45 is an opeiadonal flow 
diagram illustridng die pnxsess of releasing a call when a user terminates die 
call according to one embodiment of the invention. 

Fig. 42 is an operational flow diagram illustraling the process of 
releasing a call when a user terminates dw call according to one embodiment 
of die invention. 

Fig. 43. which is a condnuadon of Fig. 42, is an operadonal flow 
diagram illustradng die process of releasing a call when a user terminates die 
call according to one embodimem of the invendon. 
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Fig. 44, which is a condmntion of Fig. 42, Is in qieratkmal flow 
diagiam Hliutittiqg the process of releasing a call when a user lennlnates the 
call accordinig to one embodiment of the invention. 

Fig. 4S» wh' *. is a continuation of Figs. 43 and 44, is an openutonal 
flow diagiim illustrating the process <^ releasiiig a call when a user terminates 
die call aooofding to one embodiment of die Invention. 

Rg. 46 is an operational flow diagram illustradng die manner in which 
die central message processor sets iq) a call cHiginated from an opemor 
console aooondiqg to one cmbodimem of the invention. 

Fig. 47 is an operational flow diagram illustndog what occurs when 
an operstor console ori^nates a call aooordiiig to one embodiment of die 
invendon. 

Ftg. 48 is an operational flow diagram illuauating the completion of a 
call firom an operator consc^ according to one embodimrrt of die invention. 

Fig. 49lsanoperadonal flow diagram illustradng a call transfer from 
an operator console according to one enibodiment of die invendon. 

Ftg. SO is a block diagram lllustratiiig die oomponems diat 
communicate widi one anodier during billiiig server operations. 

Fig. 51 is a data flow diagram illustrsting messages sent during billing 
server operation according to one mbodimem of die invention. 

Fig. 52 is an operational flow diagram ilhistratii« die process follawed 
by die billing server when a call is received by die call processing system 
according to one embodimem of the invention. 
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Fig. 53is&bkx:kdiagnminustndiigthethitein^ooi^ 
the billing server scocmling to one erobodimem of the invention. 

Fig. S4 to a block di^iim illusmtiiig the aichitecbne of tbe billlQg 
server aocoiding to one embodiment of the invention. 

Fig. SS illuBtmtes the structure of a callbandle aooordli^ to one 
embodiment of die invention. 

F^. 36 to ft diftgrun Ulustradi« die structure of a billing information 
record aocotdir^ to one mbodimem of die invendon. 

Fig. S7, which comprises Rgs. S8 and S9, to an cperadonal flow 
du«ram illustradng die 8ie|» fbllowed by a main root procedure kernel durit« 
start-up, operidon and cleanup of die billing server acoHdii^ to one 
embodiment of die invention. 

Fig. S8 is an operadonal flow diagram illustradng die steps fbllowed 
by a main root procedure kernel during 8tart-up» operadon and deanup of die 
billing server according to one embodiment of the invendon. 

Fig. 59, which is a continuation of Fig. 58, to an operational flow 
diagram ilhistratii^ die stqis Mlowed by a main root procedure kernel during 
start-up, operation and cleanup of die billing server aooording to one 
embodiment of die invention. 

Fig. 60 to a data flow diagram illustrating dau flow between a receive 
procedure kernel, die odier procedure kemeto, billing server files, and billing 
server memory of die billing server according to one embodimem of die 
invention. 



1462.0010000 



Fig. 61 is an opentional flow dhtgiam illustrttiqg the muuM 1 1 n whid 
areoeivtpiooesBftaiKindstDagetGailhaiidfem^^ iiisoentnJ 
message processor aooording to one embodiment of the inventkm. 

Fig. 62 is an operational flow diagnm illustiadng what oo:urs wien 
die receive procedure kernel receives a start Wiling message in step ISIICl 10 oi 
F«. 61. 

Fig, 63 is an operstioDal flow diagram Ulustrating die pniosss tiiat 
occurs when a aend BIR procedure kernel recdves the stop timing, message 
sent in step EKl 14 of Fig. 61 . 

Fig. 64 is an operadonal flow diagrun illustrsdng die process of 
sending die BIR to Ae billing qniem acoofding to one embodiment of tl» 
invention. 

Fig. 65 is an operttional flow diagram iHustialing die prcctss diat 
occurs in tesponse to the receipt of a BIR check message aoocxding to one 
embodimem of die invention. 

Fig. 66 isan cpeiationai flow diagnm illustrating die process by vdiich 
die bllliog server tracks die start time of a call accordiQg to one embodimem 
of the invention. 

Fig. 67 is an opmtional flow diagram iliusoatiqg die process by »vhich 
die billing server iqidatBS die BIR for die call widi die tennination time of die 
call aooordiiig to one emlxxfiment of the inventioiL 

Fig. 68 is an operational flow diagram illiistratiiv die process by which 
die billing server sends a BIR to die billing system aooording to one 
embodimem of the invemion. 
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Fig. 69 is a blodc diagram illustrating a database server of Ae call 
processing system according to one embodiment of the invention. 

Fig. 70 is an qierational flow diagram illustrating a process by which 
the database server is created according to one embodiment of the invention. 

Fig. 71, which comprises Figs. 72 and 73, is an operational flow 
diagram illustrating the steps performed by the database server when a 
network message is received according to one embodiment of the invention. 

Fig. 72 is an operational flow diagram illustrating the steps performed 
by the database server when a network message is received according to one 
embodiment of the invention. 

Fig. 73, which is a continuation of Fig. 72, is an operational flow 
diagram illustrating the steps performed by the database server when a 
network message is received according to one embodiment of the invention. 

Fig. 74 is a data flow diagram illustrating the messages that flow to and 
from the database server when processing a network message according to one 
embodiment of the invention. 

Fig. 75 is a data flow diagram illustrating the messages involved in 
deleting a service in the database server according to one embodiment of the 
invoition. 

Fig. 76 is an operational flow diagram illustrating the steps involved 
with deleting a service in die database server according to one embodiment of 
the invention. 
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Fig. 77 is an opeittional flow diigmin illuftmii« cbe ttps involved 
in shutdqg down die databue server aooordlog to one embodiment of die 
inveittioa. 

Fig« 78A is a diagnmi illustiadog die oonfiguratton of a call ID reooid 
in call ID database according to one embodiment of the invendon. 

Pig. 78B is a diagram illiistradng the smicture of a search Icey used to 
search for a root record and further illustmdng a detedt icooni havu^ dehult 
data accordinig to one cnibodinwm of die invention. 

Hg. 79 is a block diagram illustiadng a higMevd concept of how a 
data search is performed in response to a get call ID message aoooidiiig to one 
embodiment of die invention. 

Fig. 80 is a hlgh4evel opendonal flow diagrun illustratii^ the high* 
level concept of how a data seardi in response to a gtt call ID mess^ is 
performed aocoidiiig to one embodiment of die invemiOT. 

Fig. 81 is a higb4evel operational flow diagiam illustiatiag the bssic 
stqn performed when database server lecdves a get call ID request fhmi die 
centml message processor according to one embodimem of die invention. 

Fig. 82 isadetuled operational flow diagram illustrating die manner 
in which database server searches for the ap p r opri a te data record in response 
to a get call ID message accordii^ to one embodiment of die invemion. 

Fig. 83 is a detailed operational flow diagram illustrating the manner 
in which die database server finds a root record when performing die search 
according to one embodiment of die invention. 
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F^. M b a diasnm illustntiQg a tniolation nooid aoooiding to one 
embodiment of die inveiition. 

Fig. 8S is an operational flow diagiam lllustnuing die process of 
perfbnning a number translation look-up aoooidiQg to one embodiment of die 
invendon. 

Fig. 86 is a data flow diagiam illustmdng die data flow diat oocun 
when a number tnuistadon is requested aooordiog to oik embodiment of die 
invention. 

Fig. 87 is a high-level block diagram illustradi^ an interftoe bttween 
operator consoles and die validation system aooonling to one embodiment of 
the invention* 

Fig. 88 is a bkick diagram illustratii^ die validation system illustrated 
in Fig. 87 in mbre detail. 

Fig. 89 is a high-level operational flow diagram illustradng die 
operation of die validation system aocxnding to one enibodiment of die 
invention. 

Pig. 90, which comprises Figa. 91 and 92, is an operational flow 
diagram illustrating dte steps involved in executing the p-code in die validation 
system according to one embodiment of die invention. 

Hg. 91 is an operational flow diagiam illustratiiig the steps involved 
in executing die p<code in die validation system according to one embodiment 
of die invention. 
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Fig. 92, which it « contiiiuation of Pig. 91, it an opmAani flow 
diagiain iiliutKidng the stqn Involved in execudqg the p-oode in die valldaiioo 
aystem aooording to one enbodiment of die inventkm. 

Fig. 93 is a high-level blodc diagram illiutndqg a distrttrndon qntem 
aooordi^g to one ttnbodimem of die invention. 

Fig. 94 Ib a high-level op erati onal flow di<gnun litmtiadng die manner 
in whidi die distribudon syitem updates slave databaaes to reflect updates to 
a primaiy database aocoidiiig to one embodiment of the invctttioit 

Fig. 95 is a block diagram illuitndqg a w p itsema tive aidutectiue of 
a distributor and a master datriMse in one embodiment of the distribudon 
system aoomHiy to one embodiment of the invention. 

Fig. 96 is an opendonal flow diiignm illustrating die manner in whidi 
changes are made to die master database aocofding to one embodknem of die 
invention. 

Fig. 97 is an operational flow diagram illustrating die manner in whkh 
die distributor receives events frnn die master database and updates 
distribudon tables according to one embodiment of die invention. 

P^g. 98 IS a diagram ilhistratiiig a icpteaentative configuration for an 
audit table aocordiog to one embodtmem of the invention. 

Fig. 99 is an operational flow diagram illuttnting die manner in which 
a distribution server updates distribution tables acooiding to one embodimem 
of die invention. 
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Pig. 100 is an apendonil fkw diagnin illustrating te manmr in 
whidi shve ilnmhisfn ue updated acoordiag to one embodiment of tlie 
invention. 

Rg. 101 is a Mode diagram illustrating a cepresentative architecture 
used to update the p-oode database according to one embodiment of the 
invention. 

Fig. 102 is an operatioiial flow chart illustrating the manner in which 
the i^oode database is iqxIatBd aooording to one einbodiment of die invemion. 

Fig. 103 is a bkick diagram Illustrating a diirtribudon system to update 
the p-code database according to one embodiment ijf the invention. 

Fig. 104 is a high-level block diagnm UlustraUng the MUing system 
and its interftoes to the operstor consoles and the nctworic control processor 
according to one mbodiment of die invention. 

Fig. 105 is a high-level operational flow diagram illustrating the 
process of ratii^ a call in die rate quote scenario according to one embodiment 
of the invention. 

Fig. 106 is a higb4evel operational flow diagram illustrating the stqys 
involved with rating a call in neqxxise to a billii^ informadon record 
according to one embodinttnt of die Invention. 

Fig. 107 is a block diagram illustradng die bilUng system with 
addidonal functionality aoconiing to one embodiment of die invendon. 
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Pig. 108 is an opentkmal flow diggrun illustndiv the manner in 
whidi the Ullii^ iyttero prices a call wtien a BIR is nodvd 
embodiment of the invention. 

Rg. 109 is an operational flow diagram illustrating the mamiBr in 
which die radqg system determines the wholesale cost of die call aoooidiiig lo 
one embodiment of dm invention* 

Fig. 110 is a diagram illustrating die rates for calls stored in a rate file 
accoiding to one embodiment of the invention* 

Fig. Ill is an operational flow diagram illustruing die manner in 
which the retail cost of a call is determined according to one ensbodimeRt of 
tlie invention. 

Fig. 112 is a dii^gram illustrstiqg times for which wholesale and 
bills can be computed. 

Fig. 113 is an operational flow diagram illustrating die aiq» involved 
in performing real-time billing fbr a debit caid call aoomting to one 
embodiment of die invention. 

Fig. 114 is a data flow diagram illustrating the data flow diat occus 
during real-time billing of a call placed using a debit card acoordii^ to one 
embodiment of the invention. 

Fig. US is an operational flow diagram illustrating dm steps involved 
widi determining die lemaining dollar amount on die ddrit card according I9 
one embodimem of die invention. 
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Mg. 116 is an operitloui flow diagnm Ulustndug Oie steps involved 
with leirieving deUt batch iofbrmation aooofdlng to one embodiment of the 
inventioiL 

Fig. 1 17 is an opendonal flow diagram illustradng the steps nken by 
an operator console according to one embodiment of the invention when a 
dollar amoum lemainii^ on a debit card Is insufficient to complete a deUt card 
call. 

Eg. 118 is a data flow diagnm iUustradng die messages sem in 
completing and terminating a long-disomoe call placed using a ddrit card 
acoonHng to m entbodiment of the invention. 

Fig. 119, which comprises Figs. 120 and 121, Is an operational flow 
diagram Uiustratiiv tiie steps involved in oonq^leting and terminating « debit 
card call using real-time billing according to one embodiment of die invention. 

Ftg. 120 Is an operational flow d'utgram illustrating die steps involved 
in OHnpleting and terminating a debit card call using real-time billing 
according to one embodimem of die invention. 

Fig. 121, which is a continuation of Fig. 120, is an operational flow 
diagram illusttating die steps involved in completing and terminating a debit 
card call using real-time billing according to one endxriimentof the invention. 

Fig. 122 is a blodc diagram illustrsting the data flow during call setup 
according lo one embodimem of die invention. 

Fig. 123, which comprises Figs. 124 and 125, is an operational flow 
diagcun illustrating die process followed during call setup according to <me 
embodiment of die invention. 
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Pig. 124 It an opemtkNnl flow di^gnun Uluttnting the praocn 
followed during call setup aooofdlqg to one embodiment of die inventioA. 

Fig. 125, which Is a oondnuadon of Rg. 124, is an opeiationd flow 
diagiam illustiatiqg the process Mowed duriqg call setup aooonting to one 
embodiment of the invention. 

Fig. 126 is a data flow dlagnun llhistiating die messages sent in 
completing a call according to one embodiment of die invendon. 

Rg. 127 is an opeiadonal flow diagiam ilhtstiadng die steps followed 
in completii^ a call aocoidii^ to one embodimoit of die invendon. 

Pig. 128 is a data flow diagiam illustndng die dua flow diat ocouis 
when a call is terminated according to one embodimem<rf die invention. 

Rg. 129, wMch comprises Rgs. ISOand 131, is an opeiadonal flow 
diagiam illustrsdiv die process by which a call is terminated aocording to one 
embodiment of the invention. 

Fig. 130 is an openitionid flow diagiam illustntting die process by 
whichacall isterminaied according to one eiribodimem of die invention. 

Fig. 131, whidi isacofdinuadcmof Fig. 130, is an opmtional flow 
diagram illustiating die process by whidi a call is terminated acoordii« to one 
embodiroem of the invention. 

Fig. 132 is a high-levd block diagram illustrating die use of a client 
interbce (CUP) according to one embodiment of the invention. 
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Plg. 133 is a dfavram iUustmiiv bym wittrin a diem anda server to 
handfe oommunicatlom an Etheniet LAN aoooi^ 
invention. 

Fig, 134 ii a diagnun Hlustiating the oonflguiation of a paclcet sent 
MDss a LAN acoonling to one embodiment of the inventtm. 

Fig. 13S is a data flow diagiam illuttntiDg transmission of messages 
uuqg a CUF aoomding to one embodiment of the inventioa. 

Fig. 136 is a hig|i-levd operational flow diagram illustrating the 
process followed by t CUF in haialling messages soconHog to one 
embodiment of the invention. 

Fig. 137 Is a bkKk diagram illiuttiatii^ files and tables used by a CUF 
aoooidlng to one embodiment of the inventioQ. 

Fig. 138 Is a block diagram illuttrating a request bdng sent SBKB and 
a response received by a CLIP aooording to one embodiment of the hivendon. 

Fig. 139. whidi comprises Figs, 140 and 141. is an operstkmal flow 
diagram illustrating the process by which a CUF sends and rscdves messages 
aooordii^g to one embodiment of the invention. 

Fig. 140 is an operational flow dlagrsm illusuating the process by 
which a CLIP sends and recdves messages according to one embodiment of 
the invention. 

Pig. 141. which is a oominuatlcm of Fig. 140. is an operational flow 
diagram illustrating the process by which a CUF sends and recdves messages 
according to one embodimem of the invention. 
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Fig. 142U«nopmttoiial flow di^gmm tliuMadiv what oocun when 
a fespotiK ii itoelved by a CLIP aooofding to one enbodbnenl of die 
invention. 

Fig. 143 is an opendonal flow diagnun illuttiatiiv die pnoeit dot 
oocun when a CUF receives a request aoooiding to one embodiment of die 
invention. 

Fig. 144 is a data flow diltgiam illustratii^ messages SM between a 
requesting application and a lesponding application uang CUB acooiding to 
one embodiment of the invention. 

Fig. 14S is a detailed opendonal flow diagram illustiadqg the process 
by whidi a CLIF detects die pteaenoe of a duplicaie request and pievems die 
rBspondtng application from havii^ to respond more than once according to 
one embodinmt of the inveittion. 

Fig, 146 is a data flow diagram illustradog die manner in which one 
CLIF can increase the time interval between retrws of a second CLIF 
acoordii^ to <nie embodiment of the invention. 

Fig. 147 is a detuledopersdonal flow diagram illttstrsdi^ die process 
by which a first CUF increases die time interval between retries of a second 
CUF according to one embodimeitt of dK invention. 

Fig. 148 is a data flow (fiagrsm tUustrBtuv the manner in wludi a 
CUF sends messages to an application widi a highest priority according to one 
embodiment of die invention. 
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Fig. 149 is an operational flow diagram illustrating the process by 
which a CLIP sends messages to an application having the highest priority 
according to one embodiment of the invention. 

Fig. 150 is a high level block diagram illustrating the processes and 
DEF records used by a call processing system to process calls according to 
one embodiment of die invention. 

Fig. 151 is an operational flow diagram illustrating die manner in 
which a call processing system uses DEF records and processes to handle calls 
according to one embodiment of the invention. 

Fig. 152 is a diagram illustrating the structure of a DEF record 
according to one embodiment according to one embodiment of the invention. 

Fig. 153 is a diagram illustrating how different levels of DEF records 
can be used to optimize data storage according to one embodiment of the 
invention. 

Fig. 154, which comprises Figs. 155, 156, 157, and 158, is an 
operational flow diagram illustrating the high level operator services scenario 
according to one embodiment of the invention. 

Fig. 155 is an operational flow diagram illustrating the high level 
operator services scenario according to one embodiment of the invention. 

Fig. 156, which is a continuation of Fig. 155, is an operational flow 
diagram illustrating die high level operator services scenario according to one 
embodiment of the invention. 
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Rg. 1S7, which is a continuation of Figs. 155 and 156 is ao 
opcfBtional flow diagnun illustradog the high level operator services scenario 
aocondii^ to one embodiment of die invention. 

Fig. 158, which is a continuation of Figs. 156 and 157, is an 
operational flow diagram illustrating die high level operator services scenario 
according to one cmbodimeiM of the invention. 

Fig. 159, which comprises Figs. 160 and 161, is an operational flow 
diagram illustrating die manner in which die call processing system processes 
an enhanced services card call aocordii^g to one embocfimeitt of die invention. 

Fig. 160 is an operational flow diagram illustrsting die manner in 
which die call processing system processes an enhanced services card call 
acoordiiq^ to mie embodiment of the invention. 

Fig. 161, i^ich is a continuation of F^. 160, is an operational flow 
diagram illustrating die manner in which die call processing system processes 
an enhanced services card call according to one embodiment of die invention. 

Fig. 162, which comprises Figs. 163, 164, 165, and 166, is an 
operational flow diagram illustrating a debit card calling scenario according 
to one embodimem of die invention. 

Ftg. 163 is an operational flow diagram illustrating a debit card calling 
scenario according to one embodiment of the inventi<m. 

Fig. 164, which is a continuation of Fig. 163, is an operational flow 
diagram illustrating a 6tb\i card calling scenario according to one endKxKmem 
of the invention. 
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Fig. 165, which is a oondnuatioD of Fig. 163, is an operational flow 
diagram iUustrating a debit card calling wenario acoovdiog to one embodiment 
of the invention. 

Ftg. 166« which is a oondnuation of Ftgt. 164 and 165. is an 
opeiadooal flow diagram illustrating a debit caid calling scenario according 
to one embodiment of die inveottoo. 

Hg. 167, which comprises Figs. 168, 169, 170, and 171, is an 
opeiatioaal flow diagram Illustrating dte manner in wUch a subscriber re- 
routes an 800 nuniber according to one onbodiment of the invention. 

Fig. 168 Is an operstional flow diagram illustrating die manner in 
which a sidacribo' re-mutes an 800 number according to one embodiment of 
the inventioo. 

Fig. 169, which is a continuation of Fig. 168, is an operational flow 
diagnun illustrating die manner in which a subscriber re-routes an 800 number 
according to one embodimem of the invendon. 

Fig« 170, which is a condnuadon of Fig. 168, is an operational flow 
diagram ilhistiating die maimer in whidi a subscriber re-routes an 800 number 
aooordii^g to one embodiment of the invention. 

Fig. 171, which is a condnuatkm of Figs. 169 and 170, is an 
operadonal flow dlagiam itlustrsdng the manner in whidi a subscriber re- 
routes an 800 number according to one embodimem of die invention* 

Fig. 172, is an operational flow diagram illustrating die pimmem of 
a direct^ial kmg-distanoe call. 
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ntg. 173 is a higb-fevd aichhectuitl Mock diignun tliowii^ the 
lehtkMiihip and interftoes of the taud detection and pieveatkm tynem whh 
regapd to the other relevant flystcmi (con y onem i) and diowiiv the 
ommunicatitmi pathways between the same. 

Fig. 174 is a data flow di^gmm showing the flow of the imponam 
oonunands (messages) to and from the fiaud detection and die prev en tion 
system and the other systems (components) of the present invention. 

Fig. 175 is a high-level block diagiam illustntiqg a npresemative 
arehitecture of the fnuid system acoordii^ to one entecfiment 0^ 

Pig. 176, which oomprisBS a Figs. 177 and 178, is a high-level 
opeiadonal fkyw diagtam illustrsting the steps of a genenliBed version of the 
fnuid detectioo and/or scenario aoocmliqg to one mbodiniem of the invent^ 

Fig. 179 is a diagram illuontiqg a foiled billiiig number usage reooid 
and a billing number usage record according to one embodiment of the 
invendon. 

Fig. 180 is a high-level operstionai flow diagtam illustrating the 
manner in w^lchfeurfhuid scenarios fiv a foiled call, as shown in Figs. 181, 
182, and 183, am be detected and/or prevented aooonling to one emlxxtimem 
of tht invention. 

Fig. 181 is an operational fkvw diagmm illustrating the manner in 
wiiich a foiled call auempt fraud scenario is detected and/or prevmied 
according to one embodiment of die invention. 
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Flg. 182 if an opentkmal flow di«tnun Uluttndng the numiBr in 
which a hot originating and/or terminating ANI fraud scenario It detected 
and/or picvciited aoooiding to one endxxUraent of the invention. 

Fig. 183 is an operational flow diagram illustrating the manner in 
which a Idgh usage AN! and/or high usage terndnating number firaud scenario 
u detected and/or prevented according to one enibodiroem of the invention. 

Ftg, 184 b a high-level operational flow diagram illustrath\g the 
manner in \)riiich eight fhuid snnarios lor a completed call, as shown in 
185 - 190, can be detected and/<v prevented aooordiiv to one embodimem of 
the invention* 

Fig. 185, is an openuional flow diagram illustrating the manner in 
which a hot originating AN! fraud scenario and a hot terminating fraud 
scenario are detected and/or prevented accordii^ to one embodimem of the 
invention. 

Fig. 186 is an operational flow diagram illustrating the manner in 
which a high usage billing number fraud scenario and high 800 usage fraud 
yacenario is detected and/or prevented aooordiiQ to one onbodimem of the 
invention. 

Fig. 187, is an operational flow diagram illustnuir^ the manner in 
whi^ a simulataneotts calls on a billing number fraud scenario is detecied 
and/or prevmted according to one embodimem of die invendon. 
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Fig. 188 it an opentkml flow di«gnun illuitnaii« (he manner in 
which an anomalous calls fkaud scenario Is ddeded and/or pmomed 
aoconliog to one embodiment of the invention. 

Fig. 189 is an operational flow diagiam Olustntiiv die mattner in 
which an internationa] fiaud scenario is detaded and/or picvemed aooonOng 
to one embodiment of the inventioQ. 

Fig. 190 is an operational flow digram illustndqg the manner in 
which a ^origination fraud scenario is detected and/or prevented aoooidiqg to 
one embodiment of the invention. 

Fig. 191 is an operational flow diagram tllustratiqg the manner in 
whkh a intermediate-loqg duration call fhnid scenario b detected and/or 
prevented acooiding 10 one enibodimem of dte invention. 

Rg. 192 is an operational flow diagram illustrating the manner In 
which a call cost retail fraud scenario and call cost wholesale fraud so«rio 
are detected and/or prevented according to one embodiment of the invention. 

Fig. 193 Is a data flow diagram illustrating die data flow between the 
fraud system, the validation system, and die billing server used for die 
rimultaneous calls on a billing number fkand scenario aocordmg lo one 
embodhnent of the invention. 

Fig. 194 is an operational flow diagnun ilhistnting the manner in 
which die validation system interscts witii dtt fraud system to detect and/or 
prevent fraud aooonKog to die simultaneous calls on a billing number frand 
scenario. 
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Fig. 19S is an opemtioiial flow dtagmm ilhiitnitiQg die maimer In 
wtddi the valtdadon system intencts with the billing server to delect and/or 
prevem fiaud aooonUng to the simultaneous calls m a billiog number ftaud 
scenario. 

Fig. 196 lllustiales a fmud system screen diatdiq>kys alarm thresholds 
detail information for competeted calls aooocdii^ to one mbodiment of the 
inventimi. 

Bg. I96a ilhistiates a firaud syston screen diat diqil^fs abffro 
diresholds d^l information fat felled calls aocofdii^ to one embodimem of 
tfieinventkn. 

Fig. 197 Illustrates a finuid system screen dutt displays billing number 
detail infbrmadim aooonUng to one embodimott of the invendon. 

Fig. 19g itIustiBtcs a fraud system screen dttt displays BIR informadon 
according to one embodimem of die invendmi. 

Fig. 199 illustrates a fraud system screen dua displays alarm search 
informadon according to one embodimem of dtt invendon. 

Fig. 200 illustraies a fraud system screen dmt displays BNU alarm 
status informadm with an open window showing fraud short BIR informadon 
according to one embodimem of the invendon. 

Fig. 201 illustrates a fnuid system screen dnd displays alarm detail 
information according to one embodimem of die Invemion. 

F^. 202 illustrates a fraiKi system screen diat displays short BIR 
infbramdcm according to one embodimem of die Invemion. 
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Pig. 203 UlustnlBS a fraud lystem icreen that difplayt billiaf aumber 
uatge and bikd billed number aburmi aoooidiiig to one embodtmcm of the 
invemkm. 

Fig. 204 is an operadoml flow diagnun illustntiog the process 
involved with updating dw aooountinig leooids aoooidiqg to one embodiment 
of the liffcntion. 

Fig. 2Q5 niustiatcs an eiample inqilementation of an opeiator di^bty 
scveen aoooiding to one embodiment of the invcntiao aooonfiog to one 
embodiment of the invention. 

Fig. 206 lllustntes an example <tf die openior display acieen IDustiated 
in Pig. 205 widi call information displayed diereon aooordiiv to one 
endiodiment of the Invention. 

Fig. 207 is a high-levei block diagiam illostrating a translation system 
aoooiding to one embodiment of the invention. 
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As discussed in die BackgnHind Section, leleoommunicadoitt carriers 
are Undted in the flexibility with which teir services can be provided because 
convendonal switching syttems do not address die need for introdudog flexible 
5 control into the telephone networic. An euminadon of a oonvemional 

telephone switiung systein and how it operates ilhistiates some of d^ 
for diis situadon. 

An example of a convendonal telephone s^tchiog oonfigtuadon is 
illustrsiBd in Fig. 1. Rg. 1 is a high-]e(vel block diagram lllustndng die 

10 aichitecure of a convemionai telephcme switching oonftguiaticm. Referring 

now to Rg. U the conflguradon inchides a matrix switch AA102 and an 
Qpetatitf console AAIOB. A tyfdcal subscriber AA114 to a long-distance 
carrier AA112 may be a business, anodier earner, or an individual user 
AA106, Customer AAllO may, for exampte. be a business or It may be a 

15 carrier diat is procuring enhanced services from a competitor long-dlstanoe 

carrier AAt 12. Customer AAl 10 may have its own customer switch AA104 
for routing calls between outside trunks and inude lines or instrumoits. 

Users AA106 (for example, humans talking on dw telephone) place 
long-disianoecallsusii\g long-distance carrier AAl 12. Theuser AA106 who 
20 places die call (calling par^) is termed an originadQg user AA106A. Theuser 

AAI06 to whom the call is placed (called party) is termed a terminadng user 
AA106B. 

Originating user AA106A may place die call dliecdy widi long-distance 
carrkr AAl 12 where originstif^ user AA106A is a OMtcmier of lOQg-distanoe 
25 carrier AAl 12. Where originating user AA106A subscribes to anodier carrier 

that is a customer AAllO of long-distance carrier AA1I2. die call is routed 
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througb customer AAl 10. Whefcorigiiiatii«uier AAl(NMisaD€iid-itierat 
a business that is i customer AAllO of fcM«<distaiice canier AA112 and dot 
has itt own switch AA104, that originatiqg user*s call also gets routed tfaioiigh 
customer switch AA 104. In the tetter two cases, originating user AAlOtiA is 
deemed a "client* of customer AAllO. 

Matrix switch AAIQZ is provided as a switch to mule calls between 
usefBAA106. A call is routed ton otiginating user AAIOM lo tenninatiqg 
user AA106B. Matrix switch AAia2 ^pically can nme thousamb <rf 
telephone calls smulianeously. An exainple of matrix switch AAlQZ Is the 
cotmneicially-available switch modd DMS 2S0, manuftctnred 1^ Nortem 
'Meoom, Inc. in Richanteon, Tsxas, USA. "DMS" is a fegismnsd tiademaric 
of Northern Tdeoom, Inc. 

The manner in which kmg-distuioe carrier AA112 provides k«g- 
distances services is now described. Ftg« 2 is a high-level opemtional flow 
diagram illustratii^ the manner in whidi long-dlstanoecanier AA 1 12 provides 
loi^-ditianoe telephone services to its subscribeisAAl 14. Pigs. I and 2 are 
now refiemd to in order to ilhntiate how loog-^staaoe canier AA112 
provides direct-dial long-disnuioeservioeandcpenlor-assisiBd ctHingfiDrusen 
AA106. LoQg-distanoe direct dialing b accomplished by dtelii« one phis (14) 
die called nuniber. OpemtorasslstBd callii^ can be pteoed 1^ dialh« xero 
phis (0-f ) die called nuniber or by simply dialiiig aeio 01). 

The long-distance call is originated by uaa AAi06and sem to msirix 
switch AA102. This occurs in a step AD1Q2. The call is sent over two 
channels. These channels are an audio channel AA122 and a ngnalliqg 
channdAA124. Audio channel AA122 carries die audio pcmion of die call. 
The audio portion (rf die call b referred to as call audio AA142. It is oyer 
audio channel AA122 diat die callv^s voice (m odier words, call audio 
AA142) can be heard. Gall audio AA142 can be analog awHo, digital audio. 
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or other information transferred amo^g users AA 106 in analog or digital fom 
(for example, fia or modem rignals). 

Signalling channel AA124 is used to transmit call data AA144. Call 
data AA144 inchides information regardii^ the type of telephone call being 
made and other call handlii^ panuneters includiitg called number, originating 
number (e.g., an automate number Mendfication, or ANI), how the call wu 
dialed 0+, 0), and die like. Call data AA144 also provides call setup 
parameters to matrix switch AA1Q2. 

An example of a stgnallii^g channel AA124 is die Industry stamtard 
common channel signalling system 7 (SS7) out-of4>and signalling channel. 
SS7 is typically a 56 kilobit (kbil) link, and is ccmiinonly transmitted over a 
T-1 carrier. Typically, call (faua AA144 is a data packet comprising 3(M0 
bytes of data. 

Matrix switch AA102 aocqits call data AA144 to determine how to 
handle and route die call. This occurs in a 8tq> AD104. 

If die call requires opendor assislanoe (for example, a collect call), 
operator call dam AA146 is provided to an operator console AA108. This 
occurs in a stqi ADI06. Typically, opmtor call data AAI46 is transferred 
to opemior console AA108 over a data link AA126. Operator call data 
AA146 includes informadon regarding the type of call and other information 
which matrix switch AA1Q2 knows regarding the call sudi as originating 
number, how die call was dialed, and die like. 

Operator console AAI08 is typically a manual operator omole which 
requires a human operator. The human operator answen die incoming call. 
The human operator dien sends operator commands AA128 to matrix switdi 
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AA 102 to complete the call lo the operator can verify that the called par^ will 
accept the charges for the call This occurs in a step AD108. 

If the call was instead a diitct-dtal caU, matrix switch AA102 uses call 
data /4AI44 provided over signalling channel AA124 to determine where to 
route the call. Matrix switdi AAICQ then routes the call to the destination 
number. This occurs in a step ADl 10. 

There are several problems associated with this system used by the 
conventional loi^ distance carrier. First, data link AA126 over which 
operator call data AA146 are tnuisfierred is often slower than desired and 
introduces unwanted delays in handling the call. 

A second problem is that die human operator at operator console 
AA108 only gets die information diat nntrix switch AA102 decides to send. 
In odier words, call handling is limited to the foatures and capabilities that are 
provided by die particular matrix switch AA1Q2 dmt was purchased by die 
carrier. 

Note, other manufactuiers may provide matrix switches AA102 with 
different features from diose of die DMS 2S0. Fot example, odier switches 
AA102 may have a higher data rate link AA126. However, long-distance 
carrier AA112 b sdll limited to die dioioes of matrix swhches AA 102 dot are 
commercially avulable, because it would be prohibitively expensive to design, 
develop and manufecture a custom matrix AA102. Thus, die functionality and 
cap8d)ilities diat can be provided by a long distance carrier in diis conventional 
system are limited to die functionality and characteristics provided by available 
matrix switches AA102. 

Because matrix switdies AA1Q2 are oosdy to develop, dicy are 
typically designed to provide only diose bask functions diat all long-distance 
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carrimare Ukdy todedie. In diU nttiuier, the devdopmem coits of 
switch KA\(Xl can be spicad among numerous long-di«anoe carrienL The 
cost of developing and nianofiKniriqg a unique matrix twitch AA102 is too 
high to provide a custom switch for a sif^Ie loi«-4isianoe carrier, or for only 
a unall group of loogHlistanDe carriers. As a result, custoroer-uniiiue and 
carrier-unique caliltQ feauires and services cannot be provided. 

Additionally, most manufiK:turers of matrix switdiei AAUS are unaMe 
to modify existing matrix switches AA 102 to meet uidque needs of the various 
long-distance carriers without a ngidficant cost and significant time to 
implement. 

An additional problem b dat it is 9picaUy esptidive to provide 
operator positioos Id intertee to matrix switch AAIOZ. Hits is because 
operator consoles can only interface to conventional matrix switdies AA102 
via special operator ports. Most conventional matrix switches pnmde a 
tindted number of sudi operator pcms. For examfde. the DMS 2S0 matrix 
switch AAIQ2 provides a cqiabiUty of 384 operator oonsdie ports per switch. 
Thus, in diis example, if mcue than 384 operator consoles AA108 are desired, 
at least oat additional DMS 250 manix switch must be purchased. At a post 
of approximately $2 million per DMS 2S0 (1993 prices), the cost of additional 
operator positions is high. 

This exmplt serves to illuttrate die undertyiQg reason behind die 
problems discussed in the Badcground section. Due to die Mgh cost of 
available matrix switches AA1Q2, most, if not all, of die smaller long-distance 
carriers cannot afford to puidnse or develop custom telecommunications 
switching equipment. As a result, diese carriers cannot have dieir own 
operator positions. Therefore, diese carriers must obtain high-end services 
such as operator-assisted calling diroutgh carriers AA112 who have such 
cqiabilities. 
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Additionally, for those longsiistanoe carriers who do have matrix 
switches AA1Q2, such switches AA1Q2 cannot be easily (or oost-effectively) 
reoonfigured, or customized, to meet unique call processing needs. Thus, die 
flexibility required to offer a wide range of customer services and call 
handling capabilities cannot be provided to the customers and users of these 
call processing systems AA112. 

LI n$ PnsefU InvenHon: A Simpk and EbgMiSMtUitm 

Recognizing that there was a long-felt need far overcoming die above- 
discussed limitations of the matrix switch AAi02, the inventors set forth to 
develop a simple and elegant solution for providing a flexible call processing 
system. Fig. 3 provides a high-level illustration of a call processiiig system 
AB1Q2 according to the present invention. 

As is described fully in this document, call processing system AB102 
provides a wide range of enhanced calling products and features to carriers 
and individual users. One or more carriers can use call processing system 
AB102 to obtain carrier*unique and custinner-unique, cusu)mized products and 
feabires for thdr customers. 

Call processing system AB102 includes a network control processor 
(NCP) AB104 and a matrix switch AB106. Matrix switch AB106 could be the 
same as matrix switdi AA1Q2 (for example, a DMS 2S0). Alternatively, 
matrix switdi AB106 could be a simpler type of switch as will be described 
below. NCP AB104 is a unique combination of hardware, software structure 
and programs designed and developed to control calls being handled by call 
processing system AB102. NCP AB104 is fiiUy described in detail in the 
Network Control Processor Section of diis patent document 
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Call processing system AB102 can also include one or more operuo 
consoles AB108. Opeiator console AB108 can be the same as operaio 
console AA108 used In die conventional system. However, in a preferrec 
embodiment, operator consoles AB108 provide additional features not fount 
S in conventional operator consoles AAI08. For example, operator console 

AB108 provide the capability to use customised scripts to present a carrier- 
unique intNfiee. Scri|rt8 and odier features of operator consoles AB108 art 
discussed ttuoQgfioul this document 

Types of operator consoles ABI08 can include a manual opentot 
10 console MOC AB132 ud an autmnated vofee response unit (VRU) AB134. 

MOC AB132 provides die fiincdonality required for a human operate to 
converse with die caller. Automated VRU Afil34 does not require a human 
operator to handle operator-usisted calls. Autmnated VRU AB134 includes 
stmd voice or ^yntheriad vmoe responses (automated scripts) to provide 
IS automated voice instrucdons to the caller. For example, automated VRU 

AB134 may insdruct a caller AA106A (originating user) to enter her calling 
card number. 

An addidonal tyfc of operator console AB108 includes a customer 
snvioe console (CSQ AB136. Customer service console AB136 performs 
20 customer sovicerdatedfuncdotts. These functions include givii^ credite for 

call problems and answering questions of users AA106 and long-distanoe 
carrier customers of calWprooesang system AB1Q2. 

When a call is originated by originating user AAi06A, call audio 
AA142 and call data AA144 for die call are routed to call processing system 
2S AB102. A key feature of call processing system AB102 is ttuu it enables call 

audio AA142 on audio channel AA122 to be handled separately from call data 
AA144. 
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Originating user AA 106A can be a client of a customer AA 1 10 of call 
processing system AB1Q2, or a direct subscriber AAn4 of call processing 
system AB1Q2. Customer AAllO can be a business or a carrier procuring 
enhanced services from call processing system AB102. Originating user 

5 AA 106A may place a call diitctly to call processing system AB1Q2 or through 

customer switch AA104. This is more cleariy illustrated in Fig. 4. The dmil 
of customer AAllO and users AA106 is illustrated sq»aiately in Fig. 4 for 
clarity. The term subscriber AA114 is used to generally refer to users AA106 
who are direct clients of call processing system AB102 and/or to customers 

10 AAllO. 

Calls are placed to terminatirig users AA106B. Terminating users 
AA106B may be subscribers AA114, clients of customers AAllO. or any 
other destination to which a call is placed. 

NCP AB104 receives call data AA144 via signalling channel AA124. 
IS NCP AB104 uses call data AA144 to make call handling decisions. Examples 

of these decisions include whether operator assistance is required* whether a 
number translation is required* how to bill the call, where the call should be 
routed, and die like. Also, when the call is originated, matrix switch AB106 
receives call audio AA142 from the user AA106 who placed the call. 

20 NCP AB104 dien sends switch control data AB122 to matrix switch 

AB106. Switt^h control data AB122 include data that controls call routing in 
matrix switch AB106. For calls requiring operator assistance, NCP AB104 
sends operator control data AB124 to operator console AB108. Operator 
control data AB124 includes infcmnation on how to handle the opetator- 

25 assisted call. 

Call processing system AB102 is best described in conjunction with an 
example iilustratiiig how calls are handled. Fig. 5 is an operational flow 
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dlagnm iUustntii^ die atqps involved in placiQg and oompledng a call using 
call processing system AB102. Referring to I^. 3 and S, these steps are 
nowdenibed. 

InastepAClQZ.anong^mtliQgus^AAKMAinidatesacalK Inottier 
wofds. a caller picks up the telephone and dials a telephone number of a called 
party (terminatii« user AA106B). Examples of user AA1Q6 can inchide a 
human communicadng via a telephone instrument, a te machine, or a 
modem. The oidy diffaFeaoe is that ori^nadng user AAi06A ori^nates the 
telephone call, while terminadog user AA106B is die user to whom die call 
is placed. 

The call can be routed directly to NCP AB104. or it could be routed 
to NCP ABIM via customer switch AA104. In die Istter case, customer 
switch AA104 fomaids call auAo AA142 and call data AA144 assod^ 
diis call to call prooesdqg system ABIQL Ifacustomer switch AAUM is not 
in pisce, call audio AM42 goes drecdy to matrix switch AB106 at call 
processing system AB1Q2 and call data AAI44 to NCP AB104. 

In a step AC1(M, call processing system AB102 receives call audio 
AA142 and call data AA144 for die call iiutiated in step AC102. More 
specifically, matrix switch AB106 receives call audio AA142, and NCP 
AB104 receives call data AAI44. 

in a Step AC106. NCP AB104 uses call data AA144 to determine how 
to handle die call. Spedfw details regarding dte manner in which NCP 
AB1(M makes diis determinadon are fully described in detail in the Network 
Control Processor Secdon of diis patent document. 

In a Step AC108. NCP ABI04 sends switch control data AB 122 to 
matrix switch AB106. Switch control data AB122 commands matrix switch 
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AB106 u> route the call to the cortect de:itiintioii. For example, swicdi 
amtrol ilgnal AB122 may command matrix twitch AB106 to route the call 
audio AA142 to customer switch AA104 at tlte temdnaiiag end and uhimately 
to terminatiQg user AA106B. 

The manner in which NCP AB104 commands matrix switch AB106 is 
through sending switch control dam AB122 to matrix switch AB106. The 
format and oomem of switch control data AB122 depends on the type irf 
matrix swif^h AB106 utilised. Note that in some cases, depending on die 
customer, a customer switch AA104 at die dinninathig end m^ not be used. 
In tfiese cases, die call is routed directly to iierminadqg user AA106B. 

in a step ACI 10, matrix switch AB106 routes die call to lenninatiQg 
user AA106B as ittstmcted by NCP AB104 in step AC108. 

As a result of die ftmctionality provided by NCP AB104, matrix switch 
AB106 no longer comrols die call as was die case with matrix switch AA1Q2 
in die conventional system. Matrix swiidi AB106 now slnviy functions as a 
passive switdi tint b reconfigured baaed on switch contnri informition AB 1 22 
sent by NCP AB104. 

NCP AB104 receives all die call (tata AA144 assodated widi die 
telephone call. There is no fihering or scremng perforaied before data 
AA144 u received by NCP AB104. CaU data AA144 can include, amoi« 
odier call attributes, die originatiog number, die called nuniber, and die fouie 
or circuiu activated in customer switch AA104. Thus, full control of die call 
and all its call audio AA142 and call data AA144 can be provided by call 
prooesdng system ABKC. 

A fuitter high-level illustration of die functionality of call prooesung 
system ABl(n is now described widiTtfierenoe to the following In 
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this example, an m^nating ukt AAIOM inhiatBS a call requiring operator 
assimnoe. Fig. 6, which comprises Figs. 7 and 8, is a high-level operational 
flow dii«nm iUusaatiog the ptocess that call piocessinig qrsiem AB102 uses 
to process operator-^ssi^ calls. Referring now lo Flp. 3, 7, and 8, 
originating user AAi06A initiates an operator asristed call as shown In a step 
AEIQ2. 

In a step AE104, call prooessii^ system AB102 receives call audio 
AAi42 and call data AA144. More spedfically. matrix switdi AB106 
lecdves call audio AA142 and NCP ABIM receives cell data AA144. 

In a step AB106, NCP AB104 imeiprett call data AA144 ind 
determines that wiginadng user AA106 origintted a call requiring operator 
assistance. For exan^ile, in one embodiment NCP AB 104 could examine the 
called immber and determine thit because die first number dialed is aero, the 
caller is requesting openttw astisnuioe. 

In a step AE108, NCP AB104 Instructs nuttrix switch AB106 to route 
call audio AA142 to an openuor console AB108. If a human operator is not 
required, call audio AA142 can be routed to an automated operator console 
(for example* an automaied voice response umt VRU AB134). In diis case, 
the VRUAB134 instructs die caller on how to proceed. These instrucdons are 
9|rica]ly telephone keypad button sequences to be pressed by the caller to 
conq[)lete die call. An example of dils is whm VRU AB134 instructs the 
caller to enter a calling card number. 

If a human openuor is required to handle the call, the call audio 
AA143 Is routed to a manual operator console ABt32. In diis case, die caller 
can converse widi the operstor. An example of diis case Is wtere the caller 
IS placing a collect call. 
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Where matrix switch is a DMS 2S0, NCP ABi04 singly instructs the 
DMS 2S0 to route the call to the console position iissigned to openior console 
AA108. Because opemor oonsde AB108 only gets call audio AA142, 
operator console AB108 is treated as any other destination and can be 
S identified by a terminating number. 

In a siep AEllO, NCP AB104 routes opeiator control data AB124 to 
operator ocmsole AB108 via a LAN AB128. 0|ienitor control data AB124 
instructs operator console AB108 regardii^ the handling of the call. Operator 
control data AB124 is determined by NCP ABI04 when NCP AB104 receives 
10 call data AA144. 

There is a key disdncdon between call-processirig system AB1Q2 and 
the conventional system illustrated in Fig. I. W± die conventional system, 
spedal operator console poirts are required to allow an operator ooosole 
AA108 to be interftoed to mattix switch AA102. This is became control 
IS information had to be provided by iraorix switdi AAia2 to operator console 

AA108. 

However, aooordta^ to call prooessii^ system ABIOZ, matrix switch 
AB]06onlyhasiotransfercaIlaudioAAU2toopenaDroonsoleAB108. The 
control information is prodded by NCP ABIM in die form of opentfor control 

20 data AB124. Operator console AB108 only g^ call audio AAIaI from 

matrix switch AB106. Therefore, operator console AB108 can be treated as 
if it is any odier terminadiig user AAI06B or customer switch AA104. Thus 
operator conscrie AB108 does not have to interface to inatrix switch AB106 via 
a spedal opeiator console port Therefore, the number of operstor consoles 

2S ABIOS diat can interftoe to nuurix switch AB106 is not limited to die number 

of operator console ports available m matrix switch AB106. 
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Opentor console AB108 now hai a connection with audio channel 
AA122. As noted above, operator console AB108 can be either an MOC 
Afil32 for a human operator, or an automated VRlf ABI34. 

if originating user AA106A is pladng a calling card call, originating 
S user AA106A Is prompted by opetalor consde AB 108 to enter the calling card 

number. The number is rsoelved and verified to ensure that It is a valid 
number. If die number u invalid, the user is informed that the call cannot be 
completed. This occun in a step AF1Q2 (Fig. 8). 

For valid callii'g card numbers and for collect calls, operator console 
10 ABIOB ifdtiates the ctmneotion to the terminatiog user AA106. TMs occurs 

as described in steps AP104 * AF108 as follows. 

In a step AF104, opmtor console AB108 sends operator respoine data 
AB126 to NCP AB104 via LAN AB128 indicatii« that the call can be placed 
as requested. In response. NCP AB104 sends switch control data AB122 to 
IS configure matrix switch AB106. This tells matrix switch AB106 how to route 

the call. This occurs in a step AF106. 

In a step AFI08, matrix switch AB106 is reconfigured to direct the call 
to die destination as instructed by NCP AB104. 

For a collect call, die operator asks the called party whether they are 
20 willing to accept the chaises. This occurs in a stq> AP108. 

If die called party is not willing to accept the chaiges, operator console 
AB108 sends operator response data AB126 to NCP AB104 indicating that the 
call should be terminated. This occurs in a step API 10. 
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It should be uiKlentood that the two exampln cell 
and a calling cud call are offieied as exan^ileto^ These eumples should 
not be interpreled to imply that the call processiQg syMm AB1Q2 ti limited 
to only ttiese Qfpes of capabilities. 

Call prooesNQg system AB102 provite additional value-added fieatiifts 
to tekphooe senrioes. As fully described in diis document, call piooesstqg 
system AB102 can be oonQgured lo provide the capatriUty for, amoqg other 
things, opemtiH' assioed calling, caliim card and credit caid calliQg, number 
translation and fonvardtog, leaMime call billing, and real-time caO iitmg. 

OdI ptooessiiig system AB102 can include additional systems, 
mbsystems, and fisaturea not addressed in this high-level intxvxfaiction. These 
systems, subsystems and features, discussed in dMil in the sections of dus 
document diatfbllow, are now briefly imraduoed. Rg.9lsaldgh4evelblock 
diagnm illintradng a representative architecture of call pnoessii^ system 
ABlQ2aoconfing to one embodiment It should be noted diat tills architecure 
is presented by way of example only and is not iittended to limit call 
prooessiiv system AB1Q2 to this embodiment Numeroua alternative 
architecnires can be chosen to implemem call prooesrii^ qfstem ABIOZ in 
altemstive embodiments. 

Referring now to Ftg. 9, in one embodiment, call piooessiQg system 
AB102 includes matrix switdi AB106, network control prooessmr AB104, and 
operator consoles ABICM. Additionally, call processing system AB102 
includes a validatitm systnn AG1(B, a console stanis display AGl 10, an enw 
box AQ104. a log box AG106, a fraud detection and prevention system 
AGl 12, and a billing system AGIOS. 

Validation system AG102 is provided to validate oemin pieces of call 
information before die call is ocmtpleted. lnaiisdocttmem,aGaH isconiptetBd 
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by roudiig the call to its desdnatkm (to the called paity)« Fdr example, 
validation astern AG102 may be used to detemine if a calling card mmiber 
is valid fbr the call being placed, or if a credit card number is valid for credit 
card calls. 

Error box AG104 receives problem and enor information firom otfier 
ccmiponems in call processing system ABKD. Error boot AQ104 logs this 
problem information for fotuie reference* 

Log box AG106 tiicks evenu apecific to start-up and termination of 
applioatioos on LAN AB128. These include application kng-lns and log-outs. 
Error mesiagBs leooided by error box AG104 and log messages recorded by 
log box AG106 can be tied togedier to aid in trouMe ahoodng and error 
analysis. 

Billing system AGIOS performs billing services for call processing 
syrtem AB102. These services are folly discussed in the Billing System 
Section of this patent documem. 

Fraud detection and prevention system AG1I2 is used to provide real- 
time fraud rocmitoring and detectioii. TIttsecapslNlitiesfiidlitatedetecttcnand 
prevention of firaudulent use of call processing system ABlffi. Fraud 
detecdon and preveniim ^stem AG112 is forther discussed in the ftaud 
detection and prevemicui section of this patent documenL 

Conrole stanis display AGIIO providBs numerical and graphical 
information about curvem and past nabis of rpenuor consoles AB108. 
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1.0 N^tmofkCnmolhocmoriNCn 

The Overview Secdonof the Detailed Deacripdon piovtdeiahfgli-levd 
descriiMion of how a Network Control Processor (NCP) ABIM is used id 
control call handling and perfcmn call prooesring far bng-disiance cairiera. 
S This section of die Detailed Description describes NCP AB104 and its 

imerfiMs in greater detail. 

XAi MnworftCMlrvf Aocaisor 

Pig. 10 is a blodc diagram illustrttiQg call processing qfstein ABIQZ 
in greater detail. More qiedfically. 1^. 10 ilhisttites die coinpon e nts dot 

10 conqwise NCP AB104 in one embodiment These c o mpon en ts include a 

central message processor (CMP) BA102. a database server (DBS) BAIM, a 
call route distributor (CRO) BA106, a billii« wma (BSRVR) BAIOS, a host 
gateway BAl 10 and a customer gateway BAIU. MuUpie host gateways 
BAllO may be provided to imerfiwe to muUple matrii swiidies AA106. 

IS Simihirly, muldple customer gateways BAl 12 may be provided. 

In one enilKNlimem, diese con^ionents oommunic&le widi one anodier 
via a local area networlc (LAN) BA122. CMP BA102 commuidcates widi 
operator consoles AB108 via a LAN AB128. In one embodiment, LAN 
AB128 is an ediernet LAN using die TCP/IP protocol. 

20 F^g. lOdepicts a logical (versus phyM) architecture for NCP AB104 

in terms of die iDustrated processes. This aidiitecture is chosen because it 
groups retated fimcdonslity inio sqiarate processes. It dtouU be noted tfiat 
diis is only one possible arcdiitecture for iniplemendi« NCP AB104. NCP 
AB104 can be implemented using numerous variations on diis aiduiecture. 
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The de^gn of NCP AB104 is such that praoesses within NCP AB104 
can all nin on different computers and sdll conununicate with one anotfier. 

NCP AB104 is pan of call processing system AB102. Call processing 
system AB1Q2 also includes at least one matrix switch AB106and at kastone 
operator console AB108. 

NCP ABIM intertees to matrix switch AB106 via host gateway 
BAUO. AdditkmalhostgatewaysBAllOmaybeprovided, when needed, to 
ioterface to vkBtional matrix switches ABi06. NCP AB104 also interftces to 
a customer switch via custonwr gateway BA112. In actuality, numerous 
subscribers AA114 and cutiomer gateways BA1I2 may interfiKe to NCP 
AB104. 

As discussed In the Overview Section, eadi customer AAl 10 may have 
a customer switch AA 104 to tie in one or more end users AA106 (see Fig. 3). 
A customer AAilO of call processing system AB102 can be a business or a 
small, medium, or targie telephone carrier. 

The imerftoe between subscribers AA 114 and NCP AB104 Is signalling 
channel AA124. As previously noted, in one embocUmem signalling channel 
AA124 is an SS7 channel. Customer gateway BAl 12, which Is c onn ecte d to 
signalling channel AA124, serves sevml functions. One funcdon is to 
prpvide communications and protocol conversions necessary so that NCP 
AB104 can conununicate widi customer AA 1 10. More specifically, customer 
gateway BAl 12 provides protocol conversions so diat NCP AB104 can 
communicate widi customer switch AA104. Ft^ example, where SS7 
messages are used with customer switdi AA104, customer gateway BA112 
converts die SS7 message to a message typt compadble widi LAN BA122. 
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Simitarly, host gateway BAl 10 pravtdet oommunicationt and pnUxol 
oonverrions neoeawy so that NCP ABKM can communicate with matrix 
switch AB106. Again, where SS7 messages aie uied, hoot gateway BAUD 
converts the S57 messi^ lo the mess^ type compatible with LAN BA122. 

Gateways BAllO, BAl 12 can also be implemented to convert other 
message types (such as a switch- vendor asynchronous protocol) into the 
message type con^adble vrifli LAN BA122. 

In a prefened embodiment, tbt functionali^ provided by customer 
gateway BA112 and host gUeway BAUO Is part of NCP ABlOi. In 
altemadve embodiments, this fimctionality could be proWded in gateways diat 
ate physically sepuite from NCP ABKM. 

To illustrate the functionality of NCP ABIM and its processes, an 
exanqile data flow Is now described. This data flow ilhistrams what occurs 
when a call originated by a user AA106 is received by call processing system 
AB1Q2. In this example, the caU placed Is one requiring operstor assistance. 
C^)erator assistance is not required for every call. This example is chosen to 
illustrate the additional functionallqf used to provide openoor assi sta n ce. 

Fig. 11 whidi comprises Figs. 12 and 13, is an operational flow 
dagram illttstrating the steps involved In handling a call requiring operator 
astisianoe. Fig. 14 Is a data fkw diagram illusttatiQg the data flows that o^ 
within NCP AB104 and exmmal to NCP ABKM when the caU is recdved. 
Referring now to Figs. 12, 13, and 14, dib data flow is now described. 

In a step BA202, a phone call requiring operator assistance is received 
from a user AA106. User AA106 Is using a long-distance cairier dut is a 
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custtHner AAUO oT ciH processiqg vyum AB1Q2. In this slep, call data 
AA144 is leoeived by NCP ABI04. Although any of mimeroui sfBnaling 
conventions may be used, this example is described in terms of an embodiment 
using SS7 messi^es. Tberefbie, m this embodiment, call data AA144 Is an 
SS7 message. The SS7mes8i^ is an initial address message (IAM)&A344. 

The call (tata AA144 .an include information such as the called party 
number, the calUng party number, an identification of the cusloma^ switch 
AA104 from which die SS7 message is received, an identificatxan of the long- 
distance carrier customer AAllO, an identification of die originating user 
AA106A placing die call, die digits dialed (for example, 0+ , 0*, 800+, etc.), 
die circuit location of die audio connection in custcmier switch AA104, and 
odier like information. 

In a siqi BA2M, customer gateway BAn2 sends a CALL SETUP 
MESSAGE #1 BA3Q2 to CMP BA102. In tills step, customer gateway 
BAl 12 perfonm a conversion from a call data AA144 message type (in tiiis 
example, an SS7 lAM message) to a LAN BA122 message type. CAIX 
SETUP MESSAGE #1 BA3Q2 includes all infonnatimi (i.e., call data AA 144) 
in 1AM BA344. In die SS7 example, customer gateway BA112 encapsulates 
die SS7 message data into a padcet for transfer over die LAN BA122. One 
manner in which messages are sent across LAN BA122 in a preferred 
embodimem is folly descrHied in die Client/Server Section of diis documem. 

In a step BA206, CMP BAIQS sends a GET CALLHANDLE 
MESSAGE BA304 to BSRVRBA108. GET CALLHANDLE MESSAGE 
BA304 requests tfiat a calDiandle BA3QS be assigned to tiie call by BSRVR 
BA108. Callhandk BA3Q5 is a unique number used to identify die call. 
Callhandle BA305 is used to identify die call at each phase of processing 
within call processii^ system ABKQ. Callhandle BA30S is also used to 
identify die call for billing purposes. 
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All inforntttion gatheitd for the adi it referenced to the unique 
callhandle BA3QS assigned to that call. Upon asslgmnent of callhandle 
BA3Q5» BSRVR BA108 can create or allocate ipaoe within a callhandle table 
EB132 (illustrated in Fig. 34) to store puameten, attributes, or odier call- 
related inforntttion gathered for that call. This call-rekted informatioo is 
indexed by callhandle BA30S. This infornution is used to make up a UlttiQ 
infonnation reomi (BIR) BE322 Ollustnled in Fig. SI). 

Onoe callhandle BA3Q5 is assigned by BSRVR BA108, BSRVR BAIW 
letunu a CALLHANDLE RESPONSE MESSAGE BAaS2 indicatiag the 
assignment is made. 

In a step BA208. CMP BA102 retrieves call paiameten BA3(M from 
DBSBAKM. Inlhisstq».CMPBAiQ28mlsaCALLIDRB(|UEBTBA306 
to DBS BAUM and waits for call parameters BA308 in re^xmse. Upon 
receipt of CALL ID REQUEST BA306, DBS BA104 perftmns a look-up in 
acall ID database (described insection2.4cfAis document, and in detail in 
Section 2.4.3. 1). The look-up is performed based on die infonnation included 
in call data AA144 (for example, ANI, called number, switch immber, origin 
number, origin location, M.). In one embodinot, call data AA144 for each 
call Is used as a key to search for one or more records oontaiiung call 
parameters BA308. In diis manner, tfie call processiog that is defined by call 
parameters BA308 (as described befow) can be customixed based on call data 
AA144. Therefore, call piocessii^ can be custmnixed on a per user AA106 
or per customs AAI 10 basis. In tet, call processii^ can even be customised 
based on odier <hta in call data AA144 indudiqg geographic area. 

Call parameters BA308 include information pertaining to die manner 
in which the call is to be handled by call processing system ABKG. Call 
parameters BA308 can be used to indicate whedier te originating mmifoer 
(ANI) is valid, whether the call requires operates as^slanoe, tte type of 
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operator assistance required, and other information pertaiidug to handling the 
call. 

One specific call parameter BA30B that can be used is a device amy 
list BA3S4. Device amy list BA3S4 provides informatitm used for routing the 
call to a specific (Hie or Ae operator consoles AB108. Devices listed in device 
amy list BA3S4 are ^ypes of devices diat can be used to handle the call. 
These devices can include a voice response unit AB134, a nnmial operator 
console AB132, recorded message, a receding device, and the like. In one 
embodiment, die order in which die device ^pes appear on die list indicatea 
die priori^ in which dme devices are to be selected for handiiiig die call. In 
odier woids, if die device amy list BA354 flnt Hstsa VRU AB134 type of 
operator console AB108 and dien Uats a manual operator console AB132 type, 
the call is first routed to an avaiUble VRU AB134. If aU VRUs AB134 are 
buity, die call is next routed to an avaibble manual opentw console AB132. 
This process condnues undl all types on (tevioe amy list are exhausted, or 
undl a type widi an available console is reached. 

Also included in call parameters BA308 is a lai^gu^ge field BA3S6. 
This is usefid for calls diat may require an operator (manual or automated) 
capable of responding in a certain language. The language field BA3S6 
retrieved for an incoming call indicates whedier die caller requires (m desires) 
an operator spealdt^g a particular tenguage. For exainple, one hu^gwtge fiehi 
BA356 may indfeate Spanish language operMor assistance, while anodier 
indicates Oiineae language operator assistance. The language may be 
designated baaed on any field in call data AA144. In odier words, when 
language field B A3S6 is retrieved for a call, die retrieval may be keyed on die 
originadng number, carrier idendfication, geographic area and/or odier call 
data AA144. 
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CUI|MivnctenBA308canal»iiic]iickacall9peBA358. Gall type 
BA3S8 provides ui additkmal level of diffmntiition lo that diffeient ctll 
typei cin be nwted to diflmtu types of opeialKv Oslltype 
BASSScanbeuaedtodittii^ishcalbfortvtrie^of reuras. Fm-example* 
call 9pe BA3S8can segmeitt calls so that di^ can be rauted tooperaton widi 
diffeiem attributes and/or capabilities, or lo diffeieiit types of prooesriiQ (for 
example, nuniber tnnalation). 

In one embodiment, when each openttor console AfilOB logs in to die 
CRD BA106, it provkles an openlor |»ofile. The profile contains infkmnatkn 
about die attributes and/or capaUltdes of dmt paiticutar opentor console 
AB108 or of a particular human opemtor. For example, die piofUe can 
indude inibrmatkm such as die ptocessiiig capaUlities of a omsole 
the language capabili^ of a human opemor. Fwm dris. It can be 
determined what types of calb can be handled by each opentor console 
AB108. 

The profile provided to CRD BAI06 at login, can also include 
information pertvdi^ to die level of Qpetamr expertise. This adiUdonal level 
of differeidiadon can be used to provide ceridn types o^ 
of operator consoles AB108. The call can even be directed to a qiedfic 
human operator at a manual operator console AB13Z. Thus, some of dtt 
easier calls to handle, such as rimple collect calls, can be routed to an operaior 
widi litde e xper icnDe. On die odier hand, calls leqidriog a higher level of 
operator involvement can be directed to an operator widi more experience. 

It is important to note dial call parimeten BA308 can be retrieved 
based solely on die call informadoncmiiained in call data AA144,sudi as user 
ID. carrier ID, originatii^ number, called number, circuit number, et cetera. 
No additional user input is required. As described above, call parameters 
BA308 for a call can be determined uniqudy based on call data AA144. The 
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levd of service, the ^ of operator ocmiole AB108 deilgmted, or the type 
of call processiiv provided for each suhacriber AAIM or client can be 
changed by updating call parametBts ftA308. These changes can be made by 
creating or updating die data reootds oomaining call paramciers BA308. In 
most cases, no changes to operational code ait required. 

in a siep BA210, CMP BALQ2 sends an ALLOCATE GONSOU 
MESSAGE BA310 to CRD BA106. ALLOCATE GCWSOLE MESSAGE 
BA310 can include device array list BA3S4. call type BA3S8, and language 
field BA356 received with call pacanieteniBA308 for die call. Asdescribed, 
CRD BA106 uses device array list BA3S4 and odm call paiameters BA3Q8 
to determine which console ty^ or which specific console ABIOS is required 
to handle die call. CRD BA106 examines a ocmsole usage table BA374 to 
d^rmine wldch operator ccmsoles ABIOB are avaiUble to handle Oils call. 
Conat^ usage table BA374 Indicalies in real-dme die availability of each 
specific console widiin die group of operator consoles AB108. 

In odier words, oonsote usage table BA374 is a list indicadng whidi 
operator consoles AB108 are available to handle a call, which operator 
consoles AB108 are currendy in use handling odier calls, and which operator 
consoles AB108 are odxrwise unavailable (for example, are logged off). If 
an operator at one of die manual operator consoles AB132 takes a break, for 
example, dot operator kigs off die system and the console usage table is 
automatically updated to reflect die unavailability of dud parttcufau- operator 
console AB132. VRUs AB134, and CSCs ABI36, can also tog on and off die 
call proces^ng qrstem AB1Q2. 

In response to ALLOCATE CONSOLE MESSAGE BA310, CRD 
BA106 returns a CONSOLE ALLOCATE RESPONSE message BA3I2. 
This occurs in a step BA212. CONSOLE ALLOCATE RESPONSE 
MESSAGE BA312 provides CMP BAI02 widi information such as die route 
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mimber or oonnle ID of the specific openior console AB108 asdgned 'o 
hftfidie the call. If no opcnUDr oonioka ABIOB are avaiUble 6ir any of die 
device types listed on die device amy Ust, die call is cjueued utfil an opentiir 
console AB108 which is able to take diat type of call is available. Mote 
specifically, die call is placed in a queue BA372. Eadi call may be prioritized 
baaed on when die call was queued or based on ca)l priority. This queue 
Infoimadon Is provided to CMP BAim. Muric or odier nmsi«et can be 
piovided to die caller while die caller is waiting on queue BA372. Themutk 
and messages can be customized to a particular usei AAI06 cr a paiticulaT 
custtxnerAAilO. 

A console status display AGIIO indicHes how many calls are waitiog 
on queue BA372 to lagged^ manual opeiator consolea AB132. Alternative 
notification systemi can be pnMded (such as audibte alarmi, for 
inform die opeiaton of a bwklQg of calls. In dris manner, an Indkation Is 
provided when calls are queuing up in die C3U> BA106 u seen on die oonnle 
status display AGl 10. If qum BA372 becomes loo long, a supervisor or 
anodier operator can log on and handle some of die <paeued calls to alleviate 
diebicklog. Additionally, for all operator coas(riesABI08« automatic alarms 
can be set to trigger where a specified number of calls are exceeded on dK 
queue. 

Similariy, queue information Is provided regardlog VRUs AB134. If 
a VRU AB134 queue BA372 becomes too toi«, an alarm » odier rignal can 
be used to indicate to a supervisor that a backlog is oocurriiig. The 
supervisor, or odier operator, can take apprapriale action. Appropriate action 
can include handling die calls manually or brii^ing additional VRUs AB134 
on line. 

Referrii^ agun to Fig. 1, it is importam to note dial in most 
conventiona] systems, matrix switch AA1Q2 aunrols die queiting. Tyiucally, 
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these ocmvemioaid systems only provide a queue status at periodic intervals. 
For example, matrix switch AA 102 may cndy provide queue Inftirmation once 
eveiyaOsaoonds. However, durii^ diis 3(Kseomid imerval. a situation could 
arise wh jre a number of calls are placed on hold and then the callen hai« up 
befim (be next 30-8eoond interval occurs. In this case, Iheopeiators ami die 
loQg-distanoe carrier AAIH may never know that dkeae calls were queued to 
die consoles. 

Turning again to Figs. 3, U, and 14 in call processing system AB102, 
when a call is itomved and qunied , opemtm an informed in real time via a 
console status displsy. Thus, die operators of call processing system AB1(S 
areprovidedwidi immediate notice when calls are queued. ThereasonNCP 
AB104 can provide tfiis feature isdttt NCP AB104 controls the queuing rsdier 
dum msirix switch AA102 (or mstrix switch ABIOS). Thus, an advantage of 
NCP AB104 is die potential for increased customer sadsbction by providing 
die opendon die ability to respond to call backlogs, where dtb^t patents may 
not even have an indicatkm dot a baddog of calls is occurring. 

In a step BA214, CMP BA102 creates and sends a CALL SETUP 
MESSAGEI3BA314toho8tgsteway BAIIO. CALL SETUP MESSAGE 
n BA314 provides instructions lo matrix switch ABi06 (via host gateway 
BAllO, where required) regarding comptetion of die call. CMP BA1Q2 uses 
call data AA144 lodetermhie what to inttruct matrix switch ABI06 regarding 
callroudng. Indiecaseof an operator*assisted call, CMP BA102 also uses 
GOmOLE ALLOCATE RESPONSE MESSAGE BA312 to determine to 
which console die call is to be routed. 

For die case of a direct dial call, CMP BA 1Q2 builds CALL SETUP 
MESSAGE 12 BA3 14 to instruct matrix switch AB106 to route die call to die 
desdnstion. CMP BAIQ2 determines die desdnadon by die called number. 
For an operstor-asslAed call, once a console is assigned, CMP BA1Q2 buikls 
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CAU^mt^^fg^ to inm^mm^m 

hosi gatew;^y BAl 10, when required) to route the call id ibe connect operator 
console AB108. Thus, GMP BAiQ2 uses call data AA144 to itetennine how 
the call should be routed, and dien builds CALL SETUP MESSAGE #2 
BA314 to command matrix switch to route die call as determined. 

In die case where the communications protoccHs used by matrix switch 
AB106 and NCP AB104 are different, a host gateway BAllO is used to 
provide the necessary protocol ccmversions. In this case, host gateway BAUO 
constructsaSWITCHCOMMANDMESSAGEBA316. In keeping with the 
current example, SWITCH COMMAND MESSAGE BA316 in one 
embodiment is an SS7 lAM, am. >4ll SETUP MESSAGE #2 BA314 is one 
or more LAN packets containing die SS7 instructions for switch. Thus, host 
gateway BAllO construcu and sends SWITCH COMMAND MESSAGE 
BA316 to matrix switch AB106. This occurs in a step BA216. SWITCH 
COMMAND MESSAGE BA316 commands matrix switch AB106 to connect 
the call audio AA142 portion of dte call to the qierator console AB108 
assigned by CRD BA106 in steps BA210 and BA212. 

Note that because this is an operator-assisted call, SWITCH 
COMMAND MESSAGE BA316 commands matrix switch AB106 to route 
call audio AA142 to the designated operator console AB108. For the case of 
a direct-dial call, CALL SETUP MESSAGE 12 BA314, and hence SWITOH 
COMMAND MESSAGE BA316, commands matrix switch AB106 to rcmtc 
die cdl to die called number. 

SWITCH COMMAND MESSAGE BA316 includes Information »ich 
as die originating number and die number called. Matrix switch ABI06 looks 
at die called number and determines die trunk group to which diat call is to 
be routed based on die called number. 
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U should be noted that in conventional long-du^^noe Matching syatenu, 
call data AAt44 sent by originating user AM06 Is the same ts SWITCH 
OCHMMAND MESSAGE BA316 sent to matrix switch AB106. Indiepiesent 
invention, these aie actually two different messages. In (he conventional 
system call data AA144 directs matrix switch AA102 to route the call lo die 
destination and indicates that an operator console is to receive the call first. 
In call processing ^stotn AB1Q2, switdi command message BA316commands 
matrix switch AB106 to route die audio to an opeiator console JM as if die 
opentor console Is anodier customer switch AAIM. Also, became NCP 
ABIM lecdves call data AA144. NCP ABIOi can use call data AA144 to 
mate prooessiiig determinations regarding the call, determine how to handle 
die call, and provide valuenukkd features on a per-call basis. 

As soon as host gateway BAllO sends SWITCH COMMAND 
MESSAGE BA3I6, it also sends a CAIX SETUP RESPONSE BA330 to 
customer gateway BA 1 12 via CMP BAIQ2. This oocun in a step BCIQZ, as 
shown in Fig. 13. CALL SETUP RESPONSE BA330 is an 
acknowledgemem of CALL SETUP MESSAGE 12 BA3U. 

In a stq> BC104, matrix switch AB106 sends an INITIAL ADDRESS 
MESSAGE BA31g (in one embodiment, an 1AM) to host gateway BAllO. 
This mess^ is automatically generated by matrix switch AB106 and is 
provided for operator consoles ABlOg. 

As noted above in call processing system AB1Q2, opeiator consoles 
ABlOg appear to matrix switch AB106 as if they are simply anotim customer 
switdi AA104. This is why matrix switch AB106 generates an lAM message 
BA31g for transmittal back to operator consoles ABlOg. lAM messi^ge 
BA31g is die message diat matrix switch AB106 would normally generate to 
send to die terminating switch when it is routing a call diereto. 
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In a siq) BC 106, a CAIi. SEIVP MESSAGE C3 BA320 U sett 
host gMeway BAUO to CMP BA1Q2. 

At the same time, in a step BC108. an ADDRESS COMVLBIB 
MESSAGE BA322 is sent ftom host gateway BAl 10 to matrix switch AB106. 
Address complete message BA322 is analogous to an acknowlec^ement 
INITIAL ADDRESS MESSAGE BA318. 

In a «ep BCl 10, hott gateway BAl 10 sends an ABSWER MESSAGE 
#1 BA324 10 matrix switch AB106. ANSWER MESSAGE #1 BA324 
indicates that the destinatioD to wiildi call audio AA142 is lo be ramed is 
avaibMe. In this case, because the destination is an operator console AB108, 
AraWBX MESSAGE #1 BA324 can be genenled and sent to matrix awhch 
AB106 automatically. 

If an operator console AB108 is not immedtaiely avulable to handle a 
call, die call is placed on hold in a queue BA372. In this rimatlon, ANSWER 
MESSAGE #1 BA324 is sdll sem, indicating the call is held at a sub on 
matrix switch AB106. 

In a stq> BCl 12, a CALL AGCEFTID MESSAGE BA326 and an 
AfffiWER MESSAGE 13 BA328 are sem from matrix switch AB106 m 
gateway BAllO and customer gateway BA112 to customer switdi AA104, 
CAU. ACCEPTED MESSAGE BA326 and ANSWER MESSAGE #2 
BA328 inform customer switch AA104 that nmting of the call has been 
completed* 

AAer CMP BA102 receives CALL SETUP MESSACT 13 BA320 
from host pdeway BAl 10 in Mtp BClOi. CMP BA102 aends a NEW CALL 
MESSAGE BA332 to openior 00 noleABm. TMsocouninasiqiBClU. 
NEW CALL MESSAGE BA332 infionns die specific apemor oomoleABlOB 
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chosen to taodle the call that it huanewcaUto handk. NEW CALL 
MESSAGE BA332 alao indudei call handliog information ftom a call ID 
databaae in DBS BA104. TliU infonnatlon, which can be part of operator 
control data AB124» telli console openior ABIOB how to handle die call. 

The call audio AA142 of die call la already routed to conaole AB108 
a» a resub of lAM mestage BA3 16 prevkmsly aem fhmi boat gateway BA liO. 
NEW CALL MESSAGE BA332 from CMP BA1(D (o operator convrte 
ABIOB can indude informadon such ai die IdendQr of wbaeriber AA114, 
oiiginatiQg and terminadog tekphone numben, the idendficatkm of cutfomer 
AAUO, and die outtNner client 

Oneftatiueorthepieiem InvendoniidiatdiiscallinfiBnnationcanbe 
uaed 10 cuiiDmin the call procen (br a particular subscriber AA 
AAUO, client d customer AAUO, or user AA106). For example, fbr a 
manual operator console AB132, infbrroation sudi u the name of die customer 
AAllO dirough which the call is originated can be displayed on die opentor 
console smen so diat the operttor can answer the call using diat name. Thus, 
it appears to user AA106 duu the opeiator is an opeiator working for customer 
AAllO to whidi dmt user stdncribes. Odier usefbl infbrmation can be 
displayed on the smen for die human operator's use, nieh as die caller*s 
originadng telephone number, die geogrqihic locadon of die caller, die called 
telephone number, and die geographic locadon of the called telq>hone number 

Similarly, for an automated VRU AB134, die call Infonnadon informs 
die VRU AB134 which type of call is being pind and its origin, among odier 
informadon. For exaniple, (or a calling card call ori^naied by an originadng 
user AA10SA who is a cllem of a specific cusumier AAllO, VRU AB134 
knows die identiftcadon of die specific customer AAUO, and can play (or 
symhesixe) die voice script corresponding to dim customer AAllO. Thus, 
VRUs ABI34 and manual operator consoles AB132 can be dme-ahared among 
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numerous customen AAl 10 and QKn AAIW while pi^^ 
CO user AAI06 that these operator ooosoles ABIOB aie dedicaiBd ser^oes of 
the customer AAliO to wfaicta that user AA106 subscribes. Thus. opefHor 
consoles ABIOB, both manual and automatic, can rapond uniquely lodiffaeoi 
uaen AAI06, based on who and where the user is and which cutfomer 
AAl 10, if any, is beitv uied. 

The abow example iOustnOes bow call imicessiiv system AB1G2 rai^ 
operator-assisted calls to an openlor console AB108. Fu* calls re(pilriiv other 
types of service, the operation is somewhat diflcicnL For example, fa 
requiriqg a mmiber translation, CMP BA1Q2 accesses a mubber translation 
database FA214B (see Rg. 69) in DBS &A104 to get die mnnberlD be called. 
In this situation, CMP BA102 then sends a message via host gateway BAl 10 
indicating lo matrix sv^tch AB106 the actual desdnation number so that the 
callcanbeconqileied* Matrix switch ABI06nittles call audio AA 142 to the 
terminatiqg nunter, andcustomergateway BAl 12 routes call data AA144 to 
die terminatiog switch. These call routing determinations may be made at any 
tiine during call processiiig, or even several times during call processing. For 
example, once call processing system AB1Q2 ins routed calls to an operstor 
console ABIOB and/or VRU AB134, where a called nunter hu been 
ooltected , number transladon may be perfimned upon dutt number, causing the 
call to be routed to a desdnation number, or bade to opemtor console ABIOB 
or VRU AB134. 

The discus^ above widi reference to Figs. 14 and 1 1 describes how 
an opentor-assistBd call is routed to an operator console ABIOB to provide 
operator assittnoe (in odier words, how die call Is set up). The manner in 
which call processii^ system AB102 completes die call when it is placed using 
a credit caid, debit caid, or calling card is now described. Fig. IS, which 
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compriies Figi. 16 tod 17, is a dM flow diagnm mustntiQg the dila (lows 
that oocttr within NC7 AB104 and eioenial to NCP AB104 when a calling 
card, cftdit caid, or debit card call li compieted aoooiding to one 
embodiment Pig. 18, is an opeiadonal flow diagram illustiatii« the openuion 
of conipledng a calHug cacd, debit card, or credit can! call aooording to one 
embodiment- 
Referring now to Fige. 16, 17, and 18, in a step BE^3Q(2, opemtor 
console AB108 duu is handliqg die call validtfes die card number to ensure 
diat die card used is valid. In one embodiment, diis is aooomplished using 
valkladon system AG 102 as described In die Validation System Section of diis 
documenL If die card number Is validated, opeiatar console AB108 may dieo 
rate die call* Call nuliig can be done in ootQuneticm widi debit cards to 
detnnnine when to (erminstB die call based on die amoum of dollars remaining 
in the debit card account. Rating of die call Is accomplished as described in 
die billing system secdon of dds document 

Once the call is validated and opetator console AB108 determines that 
it can be completed, opeiator console AB108 sends a CAIX. COMPLETE 
MESSAGE it BD1Q2 to NCP AB104. CALL COMPL£T£ MESSAGE #1 
BDltC, which can be part of operator response data AB126 is used on 
operator console AB 108 to indicate diat NCP AB104 can complete die call to 
die called number. This oocuis in a step BD308. 

In a step BD312, NCP AB104 determines die optimum routiiv for die 
call. In one embodiment, diis is accomplished by sending a TERMINATION 
LookHup REQUEST BD2Q2 to DBS BA104. In lesponse, DBS BA104 looks 
up die optimum route for die call and provides tiite Information to CMP 
BA1Q2. 
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In a itep BD314, NCP AB104 releaies te cdl ftm optm^oomlc 
AB108. In one embodimrat* this Is accofopllihed by fending « mmgr «d 
matrix twitch AB106. CMP MlQ2sen4s«€Qi»IJmS€AlXMI^^ 
BD2M to host gateway BAl 10. Hcnt gateway BAl 10 oonvcmOmfHUBIC 
CAIX MESSAGE BD2D4 into a FAR MS8SA<X BD104. FiUI 
MESSAGE BD104 has die effiect of tianslening die call audio ftom die 
opeiator console AB108 that wu handling the call, so it be nutted lo the 
tenninasif^ desdnation. Contimuiiginl]dsenibodimem,inatfiafwitdiAB106 
sends a RELEASE CONSOLE ME5SACT BD106 to the CMP via die 
gateway. This message is received by CMP BA1Q2 whk^ dien sends a 
RELEASE CONSOLE MESSAGE BD210 to CRD BA106. CRD BA106 
dm ideases die openoor oonsote AB108 and aends a OOraOLE RELEASE 
RESPONSE BD108 to matrix switch AB106 indicating diat die operatm- 
console AB108 is released. 

When die call is transferred from operator console AB108 in step 
BD314, CMP BA1Q2 sends an UPDATE CIC MESSAGE BD206 to BSRVR 
BA108. UPDATE aC MESSAGE BD206 updates a QC (dicuit 
idendftcadon code) status in BSRVR BA108 diat bassocialed widi die call by 
diecaIlhandleBA3QS. The GC status indicales die status of die audio drouit 
used in die call. In dds step, die OC status is updated to show a call in 
process. 

In a step BD316, matrix switch AB106 sets up the call at die 
tenninadng number. One embodimem of step BD316 is now described. In 
diis enfliodimettt, matrix switch AB106 fim sends an 1AM BDl 10 to NCP 
AB104. If required, host gateway BAl 10 converts 1AM BDl 10 to a CALL 
SETUP MESSAGE BD112. In response to CALL SEtVP MESSAGE 
BDl 12, CMP BA1Q2 sends a seccmd UPDATE aC MESSAGE BD206 to 
BSRVR BA108. This adds a CIC status to die callhandic BA3Q5 for die 
tcnninatii« audio drcuit CALL SETUP MESSAGE BDl 12 is passed on to 
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cusuuner swiidi AA104 u the tcmninatiqg end. Wtae rtquiied, customer 
gvtcwiy BAn2 converts CALL SETUP MESSAGE mU2 u an 1AM 
BDl 14. This informs customer swiKh AAI04 tlua a call is being routed. 

In a step BD918, customer switch AA104 at the terminating emi 
5 accepts the call. This is accomplialied by customer switch AA 104 sendli^ an 

ADDKESS a>MFLETE MESSAGE BD116. AUMUSSS COMPLETE 
MESSAGE BDl 16 verifies that the dieuit Is set 19 and starts ringii^g the call. 
ADimESS COMPLETE MESSAGE BDn6 is forwarded to matrix switdi 
AB106 by NCP ABKM. Again, where retpiiied. customer gateway BAl 12 
10 and host gateway BAUD perform die necessary conversions to accept the 

message and pass it on to matrix swittn AB106. 

In a step BD320, when die terminatiiv (called) party answen, an 
ANSWER MESSAGE BDl 18 is sem to NCP ABI04 from customer switch 
A A 104 at the terminatiog end. This mesiage is forwarded by NCP AB104 to 

15 mainx switch ABt06. ANSWER MESSAGE BDl 18 indicatts that die called 

party has answered die call and the parties are connected in die call. In one 
enibodimem. the ANSWER MESSAGE BAl 18 is sem from customer switch 
A A 104 to matrix switch AB106 by way of customer gateway BAl 12 and hfist 
gateway BAl 10. In this embodimem, host gateway BAl 10 provides a 

20 START TIMING MESSAGE BD120 to CMP BA1Q2. CMP BA 102 in turns 

sends START TIMING MESSAGE BDl^ to BSRVR BA 108 to start timing 
die call for retail billing. This occurs in a step BD322. 

2.a¥ aaiCampUdomforaCoUHiOdf 

The manner in which call processing system AB102 completes a collect 
25 call is now described. Fig. 19, which comprises Figs. 20 and 21, is a 

dataflow diagram illusoating the data flows thai occur widiin NCP AB 104 and 
external 10 NCP ABI04 when a collect call is completed. Fig. 22 is an 
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operational flowdiagmm illustnttng die opetitioDofO(Hiq[»letiqg a collect call. 
In completing a collect call, the opentor d^ermines the Idemificatioa of the 
calling pai^ and that the calling party ^ihei to place a collect call. The 
operuor then calls the called party to verify tfnt they win accept the cfaaiget. 
In molt cases, this is aooonqilished txmg a human cpeiafor at a manual 
operator console AB132« Alteraativeiy, the pioceu oouU be automated so 
diat an automated VRU AB134 is used to verify diat die cfaarpt will be 
accepted. This may lequlie diat originadng user AAI06A enter requested 
information via the telephone keypad and die automated oonaolc uses 
symhedaed scripts to obtain approval ftom die called parqf (also via keypad 
entry). Pordiepucposesof brevity, die completion soenuio is discussed tmdi 
reference to a human operator at a manual operator ooostile AB132. 

Referrii^nowtoFigs. 20,21,and22,dieopenioratmanuaf«jpefitor 
OHisole AB132 must first verify diat die called party will accept die charges. 
Therefore, operator console AB132 must ptaoe a call to die termioadng party 
to obtain this Infbrmaticm. To do diii, the operator at manual operator console 
ABi32 sends an ORIGINATE MESSAGE BEtQ2 to NCP ABIM. This 
occurs in a step BE302. The purpose of ORIGINATE MESSAGE B3Q2 Is 
10 place die callii^ par^ on hold while the operator oomacts die caUed party. 
This is difVerem from die scenario discussed above with reference lo Figs. 16. 
17, and 18. In diat scenario, COMPLETE MESSAGE BD102 had die effect 
of completing die call while terminatii^ die involvemem of operator oonaole 
AB108. 

In a step BD304, NCP AB104 sets up die call at mstrix switch AB106 
to route operstor console AB108 audio to die cusumier switch AA104 (where 
used) at die terminatiiQ end. In one embodiment, diis is acoon^lished by 
sendif« a CALL SE1VP MESSAGE BE202 to matrix twitch AB106 (lAM 
BE104 in one embodiment) to instruct matrix switch Afil06 tt> route die call. 
Matrix switch AB106 responds widi a message (1AM BE106 in one 
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embodiment) telling NCP AB104 that the call Is set up. An UPDATE CIC 
MESSAGE BB206 is sent to BSRVR BA108 to update the CIC to indicate 
that anodier awfio circuit is in use for that call. 

In a step BE306, die call is set up at customer switch AA104 at the 
S teraiinating end. lnoneembodimem,dilsi8aooomplldiedbysendli%anIAM 

BE108 to customer switch AAi04. Again, lAM BE108 can be a CALL 
SETUP MESSAGE BE210 aem via customer gateway BAl 12. 

Customer switch AA104 accepts die call. This is accomplished in one 
embodiment by sendii^ an AIM)]tESS COMPLETE MESSAGE BEllO to 

10 NCPAB104. AimRESSCminETE MESSAGE BBl 10 indicates diat die 

call Is accq>ted and starts fining. ADUIESS COMPLETE MESSAGE 
BEUO is forwarded to matrix switch AB106 via NCP ABi04 widi any 
protocol conversions necesauy. This is done by sending a CALL ACCEPT 
MESSAGE BEli2 from customer gateway BAl 12 to host gateway BAl 10. 

IS Matrix switch AB106 responds widi an ACM MESSAGE BE113. This 

occurs in a step BB308, 

In a step BE310, and CMP BA102 creates an ORIGINATE STAT 
MESSAGE BE212 which provides an indication to mamxal operator console 
ABL32 that die called party's line Is ringing. 

20 In a stq) BE3i0, when die called par^ answers die call, a CALL 

ANSWER MESSAGE is aem to NCP AB104 and forwarded to matrix switch 
AB106. Matrix switch AB106 in turn genemtes an answer message and 
forwards it to NCP AB104. NCP ABIM provides diis answer message to 
manual operator console AB132 indicating diat die called party has answered 

2S and die operator can request die required information. At die same time, NCP 

AB104 starts wholesale oudNxind timing of die call for nting purposes. In 
one embodiment, step BD310 is accon^liM by customer switch AA104 
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tending an answer message BEl 16 to NCP AB104. Cuittxner gateway BAl 12 
sends a call answer message BE118 to host gateway BAUO which in turn 
sends an answer message (Identical to answer message BB116) to matrix 
switi^ AB106. 

Once the opentor has verified the called party will accept the chaiges, 
the operator dien completes the call. The CMP BA102 sends a start timing 
message to BSRVR DA108 to start iMil timing. 

2.015 Sfi$c^ iMHgw^ OpMa»r HmuUiHg 

As introduoed above, operator consoles AB108 can be assigned to a 
call to provide fbteign language operator services where required or desired. 
This feature is now described. Pig. 23 is a high-level operational flow 
dii^gram ilhistratliig the manner by which call prooessiog system AB1Q2 
provides langugge-apedftc operator services. Referring now to Fig. 23, in « 
step BF104, NCP AB104 receives a call from an originatiQg user AA106A. 
More specifically, NCP AB104 receives call data AA144 fin* the call. 

In a step BF108, NCP AB104 (determines die language pneferenoe (or 
requiremem) of originatir^ user AAKMA. in one embodiment, this is 
aKomplishfid by usii« call data AA144 to retrieve a data leoord containing a 
lai^uage fteU BA3S6 dut indicates the language preference. 

In a su^ BFl 12, NCP AB104 allocates an operator console ABI08 that 
can provide the language indicated by bmguage field BA356. In one 
embodiment using an automated VRU AB134, the script played or symhesind 
by die automated VRU AB134 designated to handle die call is in die specified 
language. 
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In one endKidiinem using a minual openiDr cunsuk AB132, a script 
that appears on the acieen of the manual opemtor oonsoic AB132 for the 
hiimanopeiaeor to lead appears in the designated lu^uasr.. Alternatively, an 
indication on die opersWs screen tells human operator diat die script 
S should be read In a specific langui«e. 

TooMure diat die human operator is fluent in die requested language, 
die operator provides diis informadon when loggii^ in to die CRD BA106, 
Thus die famguage becomes a part ofdie operator profile. WhenCMPBAlQ2 
retrieves call paiaroeters BA308 and determines dua die adi requites a ipedfte 
10 language, die call is routed to die operator consde ABI32 whose profile 

indicates duit it can provide die language. 

An Alienwdve, less dedrable roediod is to allocate certain consoles out 
of a group of manual operatcir consoles AB132 fior certain languages. A 
collecnon of one or more manual cperstor consoles AB132 can be defined in 

IS an allocation table as having die capsbility to handle a specific language. Thus 

if a call is placed requiring a Spaniaih-spesking human opentfor, when CRD 
BA106 allocates die manual opetator consoto AB134, it will only allocate one 
of die collection of consoles diat is designated to have a ^nish-speaklng 
operator. In one embodiment, the language allocation tables are maintained 

20 by CRD BA106. CMP BA102 specifies die language prefinencefbr die call 

based on call parameters BA308 and CRD BA106 uses diis information in 
allocatli^ die call to die appropriate console. 

25 As discussed, NCP AB104 includes a call route distributor (CRD) 

BA106. The primary function of CRD BA 106 is to allocate an operator 
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oonsoSeABlOS CO each Incoming oil. aU>BA106 queues the inoooiiii«cill 
to a console queue BA372 when til opemor oonioles AB108 lie udlted. 
The allocation of a particular opentfor coniole ABI08 to an inoomim adl is 
based on the device Qrpe listed in device amy list BA3S4» lat^ua^e fidd 
&A3S6. and odwr infonnation contained In call paiameiers BA308. 

CRD BA 106 keeps tiack of die amount (rf time each call is in comole 
queue BA372 and provides infonnation to a console status disptey AGllO 
indicadng that calls are queued. For manual opentor oomoles ABIX^ tins 
information may be dl^layed on a omsoke scacui diqilay acraen. 

10 So dua CRD BA106 can Iceeptnck of die nundier of opentor consoles 

AB108 avaiUUe to handle calls, each opentm* console AB106 is Rquired tt> 
i^g on to CRD BA106. The logon procedute is now desciibed. 

Fig. 24 U a block diagram illustrsdng CRD BA106 and its iniertees. 
Referriog to Fig. 24, as discussed widi referenced to NCP AB104, CRD 
IS BAI06 internes via LAN BAI22 to CMP BA1Q2. CRD BA106 also 

tnttrftoes via LAN AB128 to operator consoles AB108. CRD BA106 also 
interfues to error boot AG104 and log box AG106. 

Log box AG 106 is communicated widi at die swt-up and shutdown of 
dieCRDBAI06. When CRD BA106 is started, it sends a message to log box 

20 AG106 indicadi« duu it is logged onu> LAN &A122 and opemdonal. Log 

box AG106 kecpa track of all currem processes and cw npo nems logged onto 
LAN ABI28, and dieir currem states. Login messages include die dme at 
which die application was started, die mune of die a^ilication, die version 
number, die address of die appUcadon on LAN AB128, and Its service name. 

25 Logout messages include die time at which die application terminaied, die 

name of die application, and die version number. 
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Unexpected results and enora are reported to cnor txn A0104. 

Fig. 25 is a block diagnun illustrating redundant CRDs BA106, and 
their imertee to operator consoles AB108. Fig. 25 iliustrates die inierfim in 
terms of data flows, h should be noted diat in a preferred embodiment, CRDs 
BA106 interface to operator console AB108 via LAN BA122 as illustrated in 
Pig. 10. 

F^. 26 Is an openulona) flow diagnun Ulustradrig the steps followed 
by CRDs BA106 and operator consoles AB108 when the CRDs are initialized. 

Referrirtg now to Rgi. 25 and 26 Jn a step CB102, upon initialization, 
both CRI^ BA106 communicate widi eadi other to determine which CRD 
BA106 is to be considered aprimary CRD BA106A and which CRD BA106 
is to be a secondary CRD BA106B. This determinadon is made based on 
Infimnadon contained in a CUP oonfigurstion file (Illustrated in Fig. 137). 
If diere is only one CRD BA106 available in a particular installation of call 
processing system ABI02, dttt CRD BAI06 will always be prinuiry CRD 
BA106A. 

In a stq> CB104. primary CRD BA106A sends a BROADCAST 
MESSAGE CA 122 to operattv consoles AB108. BROADCAOT MESSAGE 
CA122 oomains Information for operator consoles AB108 indicating which 
CRD BA106 is primary CRD BA106A. UtOADCAST MESSAGE CAI22 
also indicates to operator comoles AB108 dnu diey should log on to primary 
CRD BAI06A. 

When a console AB108 receives a BROADCAST MESSAGE CA 122. 
it sett a timer. This occurs in a step CB106. In one embodiment, die anrnm 
of dme set on die dmer for each console ABiOS is based on its address on 
LAN BA122. The amount of dme in the timer indicates to each operator 
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ocmsole AB108 how loi« m wahbefom mqxmd^ 
CA124. This timer function It uied lo that CKD BA106 if not overburdened 
with numerous simultaneous LOGON JGtfi(HnESTS CA124 from operator 
consoles ABIM, 

In I step CB108, each console AB108 reqxmds with a LOGON 
REQUEST CA124 at a time determined by the tinier set in step CDI06. 
Only consoles AB108 available to handle calls will le^Kind widi LOGON 
REQUEST CAI24. If a console ABI08 is nunnipecational f6r any icason, 
it will not leipond with a LOGON REQUEST CA124. Similariy. for a 
manual operstor console Afil32, a human operalior must perform, or at least 
auttnriae, the initial login. If a manual operator console AB132 b kned in 
to a primary CRD BA106A and It goes down, die mamial opeiator console 
AB132 can log on to die secondary CRD BA106B (now primary) widiout 
human operator action. Thus, if a manual opetafior console AB132 is not 
staffed by a human operator, that manual operator console AB132 cannot send 
the LOGON REQUEST CA124 to primary CRD BAI06A. 

After sending LOGON REQUEST CA124, operator console AB108 
expects a lOGON RESPONSE CA12S from primary CRD BA106A as 
shown in a step CB109. 

If operator console Afil08 does not receive LOGON RESPONSE 
CA12S after a designated timeout period. It attempts to lag on to secondary 
CRD BAI06B by sending a LOGON REQUEST CAI24 to secondary CRD 
BAI06B. This occurs in a Step CBllO. 

Operator conaotes AB108 provide a MONITOR SI€»^AL CA126 to 
die primary CRD BA106A onto which dieyaie logged. This occurs in a step 
CBU2. MONrroRSIGNALCA126isusedbylQgged^operetorconsoles 
AB108 to determine whedier die CRD AB106A that diey have logged on to 
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is still active. If apenior consoles ABIOS do not get a lesponae to 
MONITOR SIGNAL CA126 from the CRD BA106, this indicates dut CRO 
BA106 is no loqger active. 

If operator consoles AB106 are logged on to primary CRD BA106A, 
S airi no response is provided to MONITOR SIGNAL CA126, time 

send a second LOGON REQUEST CA 124 to secondary CRD BA106B in a 
stepCBllO. In this step CB110« operator console AB108 is reqimting to log 
on to secondary CRD BAi06B. 

When secondary CRD BA106B leorivesa LOGON RBQUESTCA124 
10 from an qientor console AB108, it verifies that primary CRO BA1Q6A is not 

available by sending a message to primary CRD BA106A. If primary CRD 
BA106A Is unavailaUe, secondary CRD BA106B sends broadcast message 
CA122 to consoles AB108 idendfyirig Itself as die ssM primary CRD 
BA106A. This occurs in a step CBl 14. 

IS All operator consoles AB108 logged on to original secondary CRD 

BA106B (now primary CRD BAIO^) send a MONITOR SI<»4AL CA126 
to die new primary CRD BA106A to insure diat it is sdll active. This occurs 
in a step CBl 16. 

Consoles AfilOS again set and utilize die timers for sending LOGWi 
20 REQUEST CA124 to tiie new primary CRD BA106A. 

If die original primary CRD BA106A returns to active status, it tells 
secondary CRD BAt06B (now primary CRD BA106) tiiat primary CRD 
BA106A is active and now to be considered primary. This occurs in a s«cp 
CBl 18. 
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The cpentkm resumes at step CB104. Here, primiry CRD BA106A 
sends BROADCAST MESSAGE CA122 to openior consoles AB108. 
BROADCAST MESSAGE CA122 informs opetitor consoles AB106 thtt 
primary CRD BA106A Is now active and primary. BROADCAST 
5 MESSAGE CA122 commands opeiator consdes AB108 to now log onto 

primary CRD BA106A. 

Qpmtar consoles respond by setdng their timen and sentttng a 
LOGON REQUEST CA124 to primary CRD BA106A as oocuned above in 
steps CBI06 and CBiOS. 

10 The process continues at step CBllO wherein the consoles AB106 send 

MONITOR SIGNAL CA126 tt) primary CRD BAlOfiA if LOGIN 
RESPONSE CA12S is received. This automatic reoonftguruson feature is 
benefida) in that it builds a decree of Ault-toleraiioe into die system. 

It should be noted lliat if diere is only one CRD BA106, then die 
15 processes of logging on to secondary CRD BA106B when primary CRD 

BAlOfiAfiulsdonoc^iply. In diiscaae, if primary CRD BA106Afails«diere 
is no badcup and NCP AB104 fuls the call setup process and releases the call. 

2.2 CfMiml Mmag$ Procmor (CMF) 

20 The central message processor (CMP) BA1Q2 determines how a call 

is to be processed baaed on die call data AA144 received for the call. Baaed 
on diis determination, CMP BA102 sends mess^ to other components to 
achieve the necessary call handlii^ funcdonality. For example, when a call 
requiring operator asusiaine is received, CMP BAIOl determines that 

2S operator asastanoe is required. In this case, CMP &AIQ2 sends messages to 
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DBS BA104 and CRD BA106 to determine what die call parameten BA308 
are and to have an operator console AB108 allocated to dw call. CMPBA1Q2 
then sends a command to matiix switch AB106 (via host gateway BAl 10. If 
needed) to instruct It to complete die call to the destination (See, Rg. 12). 
Thus, CMP BA102 provides die essential call handling ftinctionality of call 
procesdng system AB1Q2. 

To coorcHnaie die activides of die other components of call processing 
system AB1Q2, CMP BA102 perf6rms message handling and message routing 
in conjuncdon widi processing a call. CMP BA 102 geneiates, bandies and 
routes messages widiln NCP AB104. CMP BA1Q2 also generates* handlei, 
and routes me ssag e s between NCP BA104 and cpentor consoles AB108, and 
odier components such as log box AG106, and error box AG104. 

In one en^bodtment, CMP BA102 processes could be coded to make 
call proces»ng determinations based solely on die call data AA144 received 
for the call. However, in such a situation, a change to die manner in which 
a adl is to be processed requires software modiftcadon and re-compilation. 
Thus, in a prelierred embodiment, CMP BA1Q2 uses call data AAI44 as a key 
a> retrieve one or more data records containing call parameters BA3(K. 

Call parameters BA308 provide the information indicating bow the call 
is to be processed. Because die information about die call found in call data 
AA144 is used to retrieve call parameten BA308, call processing can be 
defined uniquely for each call. A record containing a unique set of call 
parameters BA308 could be provided for each diflerem combination of call 
data AAI44. For example, different combinations of ANl, carrier-customer 
identification, called number, geographic area, el cetera, couki each result in 
different call parameters BA308 beii% reuieved. Therefore, call parameters 
BA308, and the type of processing provided, can be defined on a per carrier- 
customer AAllO, or per-user A A 106 basis. 
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The Ainctkmali^ of 04? BA102 u now demibed wHb leferaioe to 
ahtgh-levdopentkmalflowdlagnin. Rg.27Utliig|i4evdoperitioiialflofW 
dtagnm niusaadng what occurs when a call is received from a subscriber 
AA114 by call prooesring system AB1Q2. 

5 Referring now to Figs. 10 and 27. in die step DDIOZ, CMP BA1Q2 

receives call data AA 144* In one embodiment, CMP BA102 has a callhandle 
BA3Q5 assigned to identify the call, in one enibodiment. CMP BA1Q2 
accomplishes diis « discussed sbove vrith r e fe ren ce lo step BA206 in Fig. 12. 
This occurs in step DD104. Gsllhandie BA3Q5 is used to Identify die call in 

10 call piooesiing aystem AB1(12. 

In a step DD106, CMP BA1Q2 retrieves call parameters BA308 to 
determine what type of treatment is to be given to the call. In one 
embodiment, CMP BA102 uses the infbrmttion In call data AA144 to perfkm 
a call ID and look up call parameters BA30S in a datsbase. As discussed 
IS above, call parameters BA308 can be used to indicaie how the calHs to be 

processed* Call parameters can indicate, among od»r diings, wh^r 
opemtDT assistance is required, whedier die call is to be processed, die 
preferred type of operator console AB108 to handle the call. 

If the call does not require operator assistance (illustrated by box 
20 DDI08). CMP BAIQ2 commands matrix switch AB106 to route die call to its 

desdnadon. This occurs in a step DDI 12. If necessary, oommumcations widi 
matrix switch AB106 can be made dirough host gateway BAllO asdis:ussed 
above widi reference to Fig. 10. 

If CMP BA1Q2 determines that operator asnstanoe is required based 
25 on call parameters BA308, CMP BA102 allocaies an operator console ABIOft 

to handle die call. This occurs in a step DDI 10. In one embodimem, CRD 
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BA106 b used to allocate operator AB108. This eirixxUinent is diicuaaed 
above with itfimnoe lo F«gs. 10 and 12. 

Once tlie operator conaole AB108 It allocated to handle the call 
ctquirii^ openuor assistance, CMP BA102 commands matrix switch AB106 
5 tt> route the call to that operator console. This occurs in step DD112. 

2.2.2 CMPD9M9dDueHpthm 

Fig. 28 is a block diagiam illustrating CMP BA1Q2 and its imertees. 
Referring to Dfil, as discussed widi referenoe to NCP AB104, CMP BA102 
imer&oes via LAN BA 122 to die components widiin NCP AB104. CMP 
10 BA102 also intertees to an NCP monitor DB104, an error box AG104, a log 

box AGi06« and operator consoles ABIOS, 

In one embodiment CMP BAIQ2 uses a message manager library 
DB102. Message nnniger library DB102 is a list of action records used to 
provide instructions rqearding how CMP BA1Q2 processes calls. Message 
15 manager library DBI02 is fully described below with refartnce to Figs. 34, 

35, and 36. 

CMP BA1Q2 is now described in more detail. Fig. 29 is a message 
flow diagram illustrating the flow of messages between CMP BA 102 and die 
odier processes widiin NCP AB104. Fig. 30, which comprises Rgs. 31 and 
20 32 Js an operational flow chart Illustrating the operations peifomied by CMP 

BAIQ2 in sending vid receiving die messages Illustrated in F(g. 29. In one 
embodimem, the actions taken by CMP BA102 are determined using action 
records DBI22 as described below. The manner in which CMP BA1Q2 
handles calls is now described widi reference to Rgs. 12, 14, 29. and 30. 
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In a step DE1Q2. CMP BA1Q2 receives CALL SETUP MESSAGE it 
BA3Q2. CALL SETUP MESSAGE #1 BA3Q2 includes ctll data AA144 
penaining to a call to be processed by call processing system AB 102. CALL 
SETUP MESSAGE #1 BA302 can be received directly from a subscriber 
AA114, or can be sent via a customer Gateway BA112 to perform any 
necessary pidoco! conversions. This is described idxsve in step BA204. 

Based on die information contained in CALL SETUP MESSAGE #1 
BA3(Q, CMP BA102 determines whether die call is a new telephone call or 
a call already CKisdng in call procesui^ system AB10(2. This determination 
is made based on whether there is a callhandle BA305 for die call. This 
occun in a step DE104. If CALL SETUP MESSAGE f 1 BA302 references 
a new call, CK'iP BAIQ2 determines whedier the call requires operator 
assistance. 

For a new call, CMP BA102 performs a call ID look-up in a step 
DE106. Call ID kwk-up provides call parameters BA308 to CMP BA1Q2. 
In one embodiment, this is performed as discussed above with reference u> 
step BA208 in Fig. 12. 

In a step DE108, when call parameters BA308 are received by CMP 
BA1Q2, CMP BA102 creates an initial BIR EE322 (illustrated in Fig. 51 1. 
BIR EE322 is used to store call information dial can be used for billing 
purposes. 

In a step DEIIO. CMP BA102 determines a callhandle BA30S for the 
call. In one embodiment, to determine callhandle BA3Q5. CMP BA 103 sends 
GET CALLHANDLE REQUEST BA304 to BSRVR BA108 as discussed 
above with reference to Fig. 12. When GET CALLHANDLE REQUEST 
BA304 is sem to BSRVR BAI08, CMP BA102 also sends pan of BIR EE322 
to BSRVR BA108. In diis embndimem. BSRVR BAI08 creates callhandle 
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BA30S in raponie to GET CALLHANDLE MESSAGE BA3(M, scores BIR 
EE322 (referenced by callhaiidle BA3QS) and aeiids callhandle BA3Q5 to CMP 
BAia2 in t callhuidle nwn^ BA306. 

In a step DEI12, CMP BA102 determines a call type based on call 
parameters BA308. CMPBAtOBdiendeiennineswhetha'anoperatoromisote 
AB108 is required, as illustraied by decisioQ block DEI 13. 

In a stq> DEI 14, if die call requires operator assistance, CMP BAI02 
allocales an operator console AB108 to handk the call. In one embodimenl, 
thisalkicationi8perfcmnedusin|CRDBA106. This embodiment is discussed 
above widi reference to F(g. 12 in sups BA210and BA212. 

In a step BA210, CMP BA1Q2 aends an ALLOCATE CONSOLE 
MESSAGE BA310 to CRD BA106. This message includes die call type and 
device type as determined from call parameters BA308. This information is 
used by CRD BA106 id allocate a specific console AB108 id handle die call 

In a step BA212. CONSOLE ALLOCATE RESPONSE MESSAGE 
BA3;2 returned from CRD BA106 provides CMP BA1Q2 widi die identity of 
die console AB108 chosen to handle the call. 

In a step DEI 16, CMP BA1Q2 modifies BIR EE322 for die call In 
one embodiment, diis is accomplished by CMP BA102 sendii^ a MODIFY 
BOt MESSAGE DD1Q2 to BSRVR BA108. MODIFY BB MESSAGE 
DG1Q2 insnucts BSRVR BA108 to moctify die BIR BE322 for diat call 
Cidentified by callhandle BA3Q5) to indude die idendfkation (rf die cpenuor 
console AB108 allocaied to die call. In diis manner, BSRVR BAIOS can 
handle multiple calls, each having an individual callhandle BA3QS, and each 
assigned to an individual operator console AB108. 
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In one embodimem, CMP BAIOZ reoeim a MODIFir BB 
MfSSAGE RESrmSE DG104 ftom BSRVR AAKK. MOHFY UE 
MESSAGE RESPONSE DG104 indicau dnt BIR EE122 for that cnU has 
been modified. 

5 InastepDEllS, CMPBAlCQMupthecall. Oneembodiirientof 

this call setup praoeu is discusKd dNwe with i cfei cnce to aiqu BA214 
duoaghstq»BC112inFtgs. 12andl3. lattusembodiniett,aaeriesofcaU 
setup mesoges are generated by CMP BA102 and sent to coaflguie matrix 
swiidi AB106 to RNtte the call to the dttfiwatioiL In the c$st of an opentor* 
10 assisted call, the destinadon is the openuor console allocalod in step DEIU. 

Call setup can also Include mfoming cuflixner switch AAIM as to the status 
of the call. 

In ow embocBroem, matrix switch AB106 g en ei aies and provides id 
CMP BA1Q2 a message indicadng dua the call is touted to the t c nn i nat ia g 

IS number (in dils case to dm allocaied operator console AB108). For systems 

using SS7 stgoalling, dus message Is an 1AM message. Host gateway BAl 10 
can be used to convert die lAM message into a CAUL SETUP MESSAGE 
ISDGllOfbrCMPBAlQZ. In a step DB120. CMP BA102 recdves C ALL 
SE1TJP MESSAGE 13 DGllO for die call in trmtt Cdl setup mesn^e 

20 DGllO indudes a drcutt ID code incficadqg die call route is set up in matrix 

switch AB106. In a step DE104 CMP BA102 determines dutt CALL SETUP 
MESSAGE §3 DGllO is for an exisdng call. 

In a step DF122, CMP BA1Q2 updates BIR EE322 widi die drcuit 
idendficadon. In one embocfiment, diis is accomplished by senfing a GET 
25 CALL TYPE MESSAGE 00112 to BSRVR BA108. In dils embodimem. 

CMP BAIQZ provides BSRVR BA108 with the cticuit idendficalion code in 
matrix switdi AB106 and die callhandle BA3QS for die call. BSRVR BA108 
updates die BIR EE322 for die call to indude diis new information. In 
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lespoiue. CMP BAldd Tcoeives a GET CAUL TYPB RESPONSE DQ114 
from BSRVR RA108. DGIU includes the updated BIR EB322 with all the 
changes* 

In a step DF124, CMP BA1Q2 sends a NEW CALL MESSACT 
DG116 to die opertfor console ABlOSdkicslBd to handle the call. Inttiis 
step, the allticated apentor console is Infonned dot k may accept die call 
fkom matrix switch AB106 to processing. Inonearibodimem, diealUmed 
openuor console ABICW sends a lespoose back fio CMP BAKXZ indicating dwt 
NEW CAIX. MESSAGE DG118 and die call aie meived by die operator 
console AB108. 

Finally, in a step DF126, CMP BAIOZ sends CALL SETUP 49 
lespome DG118 to host switch gateway BAllO indicating dial openHor 
console AB108 can start processing die call. 

In one embodiment, CMP BA102 processes messages using message 
manager DB102 and a set of acdon records DB122. Message manager DB102 
maintains a table of all netwcwk requests or messages die CMP BA102 ccwld 
receive and a Callback InitiaUatkm Funcdon that initiaies die processing of 
each netwofk message. Bach function call is accomplished usiqg an action 
record ^icfa Indicates die actual code to execute tc begin processing die 
networic message, in addidon« CMP BAIOZ maintains a list of action records. 
These action records define a single task and can be chained tog^her to 
perform a series of tasks diat must be executed to fiilfill die network request. 
When an acdon record chain is inidalixed, message maratger DBKD takes 
ocmtrol of executii^ die sequence of ai^cms until die end of the sequence is 
reached. The next action to be performed in the sequence is baaed on a 
Remm Type and a Return Code received in die current action recad. 
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R^ro typecanbeddieraFunctkmRecumoraNe^^ A 
Function Return indicatei an action that can be executed imnediaiely because 
the next action mord in the sequence contains a function call. A Networfc 
Return indicates an action that is delayed because a response must be received 
over the LAN. An acdon record may contain any nuniber of posnble 
FunctiiMi Returns or Network Returns. Each Functbn Return and Netwvoric 
Return is further identified whh a Return Code. For evh funotimi Return 
Code and necworic Return Code there is a points to indicate tbt next action 
record to move to when die current action is con^ilmd. The application will 
move to the tnu acticm record in die chain based on die Return Type and 
Return Code received in die current action. 

Defimlt Networic Return Code DM114 and its nett action pointer 
DM 1 16 define the next action reoord in die sequence for ^lis network Return 
Code. 

Fig. 33 is a diagram iilustratii^ an example of an action record. 
Rr ferriog now to Fig. 33. in this action record DM100, a Number of Function 
Returns DM 106 indicates diat diere are three possible Functicm Return codes, 
including die Detedt DM110 contained to diia action reoord. DM1 IS and 
DM 120 indkate the two possible Function Remm Codes and that Next Action 
Pointer. Action Record DM 108 indicates dutdiere are four possible N^work 
Return Codes, inchidiog die Defiuilt DM114 oontuned in diis action record. 
DM122, DM124,and DM126 indicate die diree possible Network Return 
Codes and Aeir Net Aoion Pointer. 

The manner in which Message Manager DB102 uses Action Records 
to fUfill netwofk requests is now described. Fig. 34, which comprises Ftgs. 
35 and 36, is an operatimul flow diagrun iUustnoing die process by wiiidi 
Message Manager DB102 uses Action Records DMIQO to process a network 
requesL 
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Rcfen1i« now to Ftg. 35 CMP BA102 leoeives a network vequest in 
a step DMm Message Manager DBIOZ looks in its table to find the 
CaWiack Mtialhation Function tat initiates the processing of the network 
message received and the Actkm Record DM 100 at which to bqpn processixQ 
the message. In a step DM203, Message Manager DB102 executes die action 
pointed to by die current Action Record. 

In a step DM204 Message Manager DB102 reouves a response 
oontaiini^ an MioQ Return T>pe and an action Return Code. Depending 
upon tiie action Return Type and die action Return Code received when die 
current action is oompleted. Message Manager DB102 moves to die text 
action leoord as determined by die Next Action MiMer DM 1 12. Message 
Manager DB102 kioks at die response to determine if die response is a 
PUittdon or a Netwmk type in step DM2Q5. 

If the response received is a Function response, in a step DM206, 
Message Manager DB102 looks at die Return Code recdved to determine if 
it matches any of die Return Codes contained in die current Action Reond 
DM100. Ifainatch is found. Message Manager DB102 moves to step DM208 
and executes die next action record indicated by die Next Action Mnter 
DMU8 associated widi die R^iu Code fiound. Message Manager DB1Q2 
continues widi dils process of eiecudr^ die current Ac^ Record DM100. 
reading die Return Type and Return Code and movii^ to die next Action 
Record DM100 until no more records can be found. 

If no match is found for die Return Code DM100 in step DM20b, 
Message Manager DB102 looks at die cunem action record for a Defiuilt 
Function Return Code DM 110 in a step DM210. If die Detolt exists, 
Message Manager DB102 moves to step DM212 and executes die next action 
record indicated by die Next Action Piointer DMIU associated widi die 
Defoult Function Reoim Code DM 1 10. If in a step DM210 die Action Record 
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does not oomiin any Function Returns, the Number Fiinction Returm DM 108 
value in the action record DM100 is equal to aero and processinig of the 
networic message received by CMP BA10(2 is oompieted. 

If step DM2Q5 indicaies diat the response received upon execution of 
die Acdon Record DMIOO was not a function Response Type it is a Network 
Response Type, and die operation condmies at a step DM320. Because all 
reqxmse types will always be ddier a Puncdon or Networic Response Type, 
Ing. IS details processing of « Networic Response Type. 

Referring now to Rg. 36, in step DM320, die respcmse received is a 
Netwwlc response so Message Manager DB1Q2 looks at die Return Code 
received to determine if it matches any of die Return Codes contained in the 
current acdon record DMIOO. If a match Is found, messige manager DB102 
moves to step DM322 and executes the next acdon record DMIOO hidicated 
by die Next Action Mnter associated widh die Iteturn Code found. Message 
manager DB1Q2 comimies widi diis process of executing the ourrcm action 
record DMIOO, reading die Return Type and Renirn Code and niovii^ to die 
next acticm record DMIOO until no more records are found. 

If no matdi is found for die Return Code reodvod in step DM320. (t.e. 
if no more action reoorda DM 100 are found). Message Manager DB1Q2 looks 
at die current Action Record in a step DM324 for a DeGuih Networic Return 
CodeDMlU. If die Defauk Networic Renrni Code DMIH exists. Message 
Manager DB102 moves to step DM326 and executes the next action record 
DMIOO iodlcalBd by die Next Action Ptnnter DM116 assodated widi die 
Default Return Code. If die Action Record does not conlain any Network 
Returns, die Number of Netwrak Returns DM108 value in die action record 
is equal to aero and prooessiQg of die networic message received by CMP 
BA102 is oompletBd. 
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Uang AcAm Reeonto to process netwoik nqatM allows that 
^)plu;atton to lie easily reoonfiguitd to Incoipoiite new network messages and 
features. ActionReoordsaiealsoeasily read for trouble shooting of the oode 
itself. By looking at the actkm record chain or sequence a reader can quicMy 
understand the wortdiig of the nMwork request C at invokes it 

2.2.4 NM$»mrnwukalMorlKn€i4»UL^^ 

As discussed stove wtOi reference to FIG. 31 , CM? BA102 determines 
whether die call reoeivod by call processing ^stem AB 102 requires operoor 
assistance. As indkaied by decision Vbdk DBI 13 Cilhtstfated in PIG. 31) if 
the call does requires cpenuor sssistsnne, an operator console ABI08 is 
aitocated to handle the call in step DBI14. However, if the call does not 
require opetator assisiaiioe, it can be completed without die asiistanoe of an 
operslor console AB 108. TWo examples of when diis may occur b when the 
call requires an 800 translation, or when die call is simple a direct-dial lot^* 
distance (1 +) call. The manner in which these Qfpes of calls are completed 
is now described wiA refeoioe to Fig. 37. 

Hg. 37 is an operational fknv diagram illustrating die manner in which 
calls dut do not reqiure operator assistance are completed. Referring now to 
Fig. 37, in a Step DHl 12, CMP BAIQZ determines the correct number plan 
area (NPA) for die call. An NPA is cmmonly known as an area code that 
designates a toll center witfiin the United Soues, Canada and Mexico. Insome 
embodiments, it may not be necessary to determine die NPA dqpending on 
where call processing system AB102 is implemented and the ^pes of calls it 
is designed to handle. 

In one embodiment, die NPA is determined by sending an NPA kiok 
up request to DBS BA104. In response, DBS BA104 determines the correct 
NPA and returns a re^onse to CMP BA1Q2 indfcating die NPA. 
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In a step DHl 16. die tenDioadi^ NPA it determined by CMP RAICD. 
This is aooompltihed in a maimer umilar to die manner in which CMP BA 102 
determined die originadng NPA in step DHn2. CMP BA102 uses die 
originating and die tenninadng NPAs to detemiine die touitig far dw call. 
At diis dme die call can be set tip. Addidonally die NPAs can be used to 
determine time offsets between the origin and teminatioii, lo dcitiiidiie 
whedier daylight-iaviiigs time is in effect, to detennine die teognpbk locatioii 
of die origin and termination, and to detennine a local access tiinspoct aiea 
(LATA). These items correspond to fields in die BIR EE322 (BilUi« 
Information Record). 

In a step DHl 17, CMP BA1Q2 determines whedier die call requires a 
number tianslatioa. An example of a number translation is a MO number 
translatkm or a 900 nuiAber tiinslatkm. 

If die call requites a number transbtion, die oaitthoion is p^farmed 
in step DH1I8. In one embodimem a translation look-up i ^*«iuest Is sem to 
ros BA104. DBS BA104 receives die request and looks up die correct 
nundierinatruislationttatahase. This translated number b provided to QIP 
BAI03 as die correct tenninadng number for die call. If die call is a direct- 
<Bal .king-disianoeca]l diat does not require operator assistaise. step DH118 
is bypassed as indicated by fkiw line DH 163. 

In a step DHl 19, CMP BA1Q2 does a termination hsok-up to detemiiiie 
die routir^ of die call and verify die tennmating numben. 

In a step DIU20, CMP BAIOZ sends CAU. SET UP MBSSAGS 
BA314 to set up die calHn matrix switch AB105. Asdisaaaedabovcinone 
embodiment, CALL SET UP MESSAGE BA314 Is sem via host gateway 
BAllO whidi omvertt it to a message type oompatible widi tint of matrix 
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iwilch AB1Q6. The effect of ihis step DH120 Is to «et up the routing of the 
call in matrU switch AB106, 

When nuUrii switch ABI06 acknowledges that it hu teoeived the 
message atri is set up for the call« CMP BAICD sends a CALL SET UP 
RESPONSE BA330 to customer switch AAIM. Again, in one embodiment, 
diis message it sent via customer gateway BAn2. At diis time, die call is set 
up to be completed to die temunatiiig party. 

lnastepDH126, CMPBAIOZ sendsarequestto matrix switch AB106 
to oomplete die call to die lermlnating party. This request can be sent via host 
gateway BAllO. 

When a call is being processed by an operstor oomokt AB108. it could 
have more tfian one audio leg. For example, a collect call has two audio 
dmnnels AB122: one for die originadng party and m for die terminadng 
party (to verify dutt charges are accepted). If die console has to release a call 
during processing, it first releases die terminator, and dien die ori^nator. 

The manner in whidi a call is released from a console Is now 
described. Rg. 38, wUch conq^rises Figs. 39 and 40, is an opemdonal flow 
diagram ilhistiating die manner In which CMP BA102 releases a call from an 
operator console AB106. Referrif^ now to Fig. 39, when openfiM' console 
AB108 determines diat it is Co release a call it sends a release networii request 
message to CMP BAi02. This message is received by CMP BAlOl in a step 
DJ104. 

In a step DJ106, CMP BA102 determines vriiedier die call leg bdng 
released is in an originating leg, or whedier it is a terminadng or auxiliary teg. 
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If it ii mi origiintii^ leg the opention coadmwt in a Ifdiecill 
leg ii a termiiiatii« or aiailiaiy leg, the operation oootinyei in a ftep OJ2I2. 

For calls in the originating leg, inasiepDJllO, CMPBAl(l2tta|Mttie 
inlbound timing of the call. In one embodiniem thii is weomplUM 
lending iiequeA to Slop the inlxmndtinuqg to BSRVRBA108^ Uponnodpt 
of this message, BSRVR BAIOB stops the inbouid whoksdenetwoik timing. 
BSRVR BAKK also sends a response to CMP BA1Q2 Indcatiqg that the 
irixnind wholesale timing has been slopped. 

In a step DJ114, when CMP BA102 receives the loponae frem 
BSRVR BA108 Indicating that the inbound timii« is slopped, CMP BAICQ 
upttaM ihe BIR EB322 for die call. This is aoomiplished by sending in a 
lequesttoBSRVRBAlOStoupdatetheBiREEm. BSRVR BAIOS intoies 
that die BIR is updated by sending a reqmme lo CMP BAIOZ. 

Upon receipt of dils lespome, CMP BAI02 releases die call in a step 
DJl 18. In one embodimem, this is accomplished by sending a call release 
request to die host gateway informing the host gaieway dnt die operator 
console AB108 is releasing the call. Host gaieway BAllO reforaiatt diis 
message where necesmry and forwards it to matrii switch ABI06 indicating 
diat the console ABI08 is rtleasii^ the call. 

In a step DJ120, die CIC is deleted from BSRVR BAIOB. In one 
endNxliment, ttiis is nooonqilished by CMP BAIOZ senfing > retptest to 
BSRVR BA108 to delete die QC. For every call, BSRVR BA108 maintains 
callhandle BA3QS, CICs (audio cireuits idendfiers). a BIR EEm, and call and 
network timing information. One omditloa is thst BSRVR BA108 ship BIR 
EE322 to billing system AGIOS for tatiiQ when the billing server has no more 
CICs associated witti a call. For diis reason, BSRVR BA108 is informed by 
CMP BA102 when an audio drcuit is added or deleted. Circuits are added 
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upon call let up and origimdcm and deleted upon call rrieaies and oompletet. 
Becauae opeiator console ABIOB is leteari^g die call in dils scenario, CMP 
BAIOZ deletes the CIC in step DJ120. 

In a step DJ124, CMP BA1Q2 frees operator oonsoie AB108 from the 
calK In one mbodiroent, diis is nocomplislied by sendiqg a request to CRD 
BA106 to free the console. In response, CRD BA106 reteaaes the oonstte 
AB108 from die call. Freeing operator console ABI08 widi CRD BAI08 
makes that particular console AB108 available for handling anodier call. As 
discuaed itove, CRD BAIOB keeps tiack of availaMe operator consoles 
AB108. In a step DJ208, CMP BA102 releases opentttr console AB108. 

If die call bdqg released is for a terminating or auxiliary leg, in a step 
JD212 die oudwund timing of the call is stopped. This is accomplished by 
wKifyingBSRVRBAlOS to Slop outbound tim{i«fbr die call. BSRVRBAiOS 
In response, slops oudiound wholesale network timing and pravkles a response 
to CMP BAi02 ImHcadng such. 

When CMP BA102 receives die response from BSRVR BA108 
indicating d»t the inbound timing is stopped, CMP BAIQ2 i^Nfaues die BIR 
EE322 for die call. This is accomplidied by sending a request to BSRVR 
BA108 to update die BIR BE322. BSRVR BA108 Indicates diat the BIR is 
updated by sending a ttsponae lo CMP BA102. 

Upon receipt of diis response. CMP BA102 releases die call in a step 
DJ2I6. In one embodiment, diis is accomplished by semBnS a call release 
request to die host gateway informing die host gateway dmt die call is being 
released. Host gateway B A 110 reformats diis message where necessary and 
forwards it to matrix switch AB106 indicating diat die oonsoie AB108 is 
releasing die call. 
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In a step DJ220, the aC u deleted from BSRVR BA108. In one 
erobodimem, diis is aooomplisbed by CMP BA1Q2 tending a icguest to 
BSRVR BA 108 to delete tbe CIC. 



12.6 CattRHtmPinmASwM 

Pig. 41, whidi comprises F^. 42 through 45 is an opeiational flow 
dh^gmm illustrating the process of leleasiqg a call when a user AAI06 
tenninates die call. Referring now to Hg. 42, If originadng user AA106A or 
terminating user AA I06B terminates die call (for example bangs up the phone) 
customer switch AA104 sends a request to release die call to NCP AB104. 
In one embodiment, this is received by custtmier gatewiy BAl 12. Customer 
gateway BAI12 converts diis mess^ to die format recognized by CMP 
BA1Q2 and forwards it to CMP BAI02. Hiis b illustrated in die step DKIM. 

In a step DK108, CMP BA102 determines wbedier the console 
identifier is valid. In one embodimem CMP BA102 determines whedier an 
INET address and socket number are valid. If they are not valid, in a step 
DiG02 dw call is released at customer switch AA104. 

If, on die other hand, the console ideittification is valid this indicates 
diat die request to release die call came fhrni die matrix switch AB106 via host 
pteway BAl 10. In diis case, in die step DK112, die network is terminating 
via operator console ABIOS. To accomplish dua, CMP BA102 sends a 
terminating request to operator console AB108. 

If, in a step DKl 16, a remm code received by operator console AB106 
in response to die terminate request is vaKd, die call is released at matrix 
switch AB106. This is accomplited by sendir^ a call release response to 
matrix switch AB106 via host gateway BAl 10. This is ilhistraied in a step 
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DK120. A coponie ii then lent to customer twitch AA104 via cunomer 
gateway BA112 Indicatiog the call is released. 

If, on tlie other hand, the return code is invalid, CMP BAIQ2 frees 
opentor ocmsole AB108 In a step DK2Q2. This is woomplished in one 
embodiment by sending a lequest to CRD B A 106. to finee the opemor console 
AB108 and make it available to handle odier calls. 

In a step DK208, the CIC is deleted at die BSRVR BA108 and in a 
step OK210 die call ndease leaponse is sent to die matrii switch AB106. A 
rnponse is dia sent to customer switch AA104 via oistooier gateway BAl 12 
indicadqg die call is released. 

If console address identification wu invalid in step TOClOfi die call 
release request was received from customer switch AA104. In this case, the 
call is released in mp DK3Q2. In one embodiment, this is aoooai|riished by 
sendii^ a request lo matrix switch AB106 (via host gateway BAl 10, if 
required) to release die call. 

In a step DK304, CMP &AIQ2 determines whether die call being 
released is queued at CRD BA106. If it is not being queued at CRD BA106, 
the CIC is deleted at BSRVR BA108 and a call release response is sent to 
customer switch AA104 via customer gateway BAl 12. This is illustiated in 
steps DOM ami DK30B. 

If, on tht other hand, die call being reieaaed is queued at CRD BA106, 
the call is freed from die queue. InoneenAodiment, diis isaoconvllshedby 
senditQ a request to CRD BA106 to free die queued call. TMs occurs in a 
stepDK404. 
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In a step DK408, BIR BB322 is modified at BSRVR BA108 to chaiwe 
the call qum time. CRD BA106 maimains ihe duntion of queued calls. 

In a step DK412, BIR BB322 is modified at BSRVR BA108 to modify 
the tenninadon method of the call. Hus isaooompHshedliy sendlogacequesi 
to BSRVR BA108. 

InastepI>K416 CMP BAI02 deletes the aC in BSRVR BAIOB and 
in a step DK418 seat CMP &A102 releases the call by seodiiv a call release 
response to customer switch AA104 via customer gsteway BA112. 

2.2.7 CMSH^f^mOtmtaf^€^mU4)ri^MM€M 

The manner in which CMP BAi02 sett up a call when an opemtor 
console orlgbiates a call is now described. Pig. 46 Is an opentkml flow 
diagram illustiatii« die manner in whteh CMP BAICB sets up acall originated 
fromanoperstoroonsc^ABlOS. RdMng wiwtDFig.46, whenanopeiator 
console AB108 originates a call, it sends an originate ^vsquert to CMP BAKQ. 
0|>:rat9r console AB108 may originate a call, when making a collect call to 
verify that Ihe called party will accept the charges, or when calling a customer 
to tell die droe and charges of a call. In a step DL104, the request to 
originate the call is received by CMP BAKQ. 

In a step DL108, CMP BAI02 determines whether calOiandle BA3Q5 
is valid for the call. If it is valid, the opeiadon contimies in a step DLt20. 
If callhandle BA30S u not valid, in a step DL112, CMP BAIQZ sends a GET 
CALLHANDLE REQUEST BA304 to BSRVR BA108 to assign a valid 
callhandle BA3Q5 to die call. 



1462.0010000 



2116162 

- 110- 



In a itep DL116. when CMP BAUD reoeivet caHhandle BA3QS ftom 
BSRVRBA108Jtmd8areqiiesttoCIU>BA106(ooiigiDalethe^^ Upon 
leoeipt of diii request, CRD BA106 muks the oonaote AB108 as buiy. 

In a step DL120, CMP BAIOZ leti up the call at matrix twitch AB106. 
[n a Acp DL122 CMP BAIOS adds a CIC in BSRVR BA108. In one 
embodimem, diis is aoooiiq>lisfaed by sendiiig a request tt> BSRVR FA108 to 
add the ac far the call. 

In a step DL124, CMP BA102 ioforais operator oonic^ AB108 that 
the call is being originated. 

Pig. 47 is an operational flow diagcam iliustiating what occurs whe. 
an opeiator console origlnBtes a caU. When an openuor console AB108 
originates a call, acommand is smt to matrix switch AB106 to route die call. 
Matrix switch Afil06 provides a lesponse to CMP BkVO,, In one 
embodhnoit, this response Is trandated by host gateway BAllO to a CALL 
SET UP REQUEST message to CMP BAIOZ. CMP BA1Q2 receives CALL 
SET UP REQUEST mess^ in a step DL204. 

In a step DL208, CMP BAKU sends an add QC tequest to BSRVR 
BA108. This request contains die switdi and circuit ID infimnation to be 
contained in die CIC. In a step DL212, CMP BAKU sets up die call at 
customer switdi AA104. This is aoooniplidied by sending a call set iq> 
request via cuttomer gateway BAl 12. InasCEpDL2l6,aca]lseti^re%xinse 
is received from customer switch AAIM via customer gateway BA112. A 
response is forwarded by CMP BA1(Q to msoix swinh AB106 via host 
gateway BAl 10 where requited. 
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The manner in whldi a call Is completed from an operator conaole 
AB108 is now described I^. 48 is an operational ftow {Hagtam iUusMti 
the completion of a call from an operator console AB108. RefiBrring iiow to 
Fig. 48, in a step DL304« opeialor console ABiOS sends a request to CMP 
BA102 that te call be compietedthrm^ the networlc. CMP BAKB tej:dves 
this request fiom the operatiir console AB108. 

To determine touting for die call, CMP BA102 performs a tmnination 
look up. In one enibodiment, diis is accomplished by sending die request to 
a termination database via a database server (such u DBS BM04). In this 
step, opdroum roudng for die call is determined. 

In a step DL312, CMP BA104 sends a request to billtt« server BA108 
to update dw BIR BB322 for die call. Additkmally, CMP BAIQZ instnx^ 
billing server BA108 to delete the CIC for die call in die console AB108. 

In a st^ DL316, CMP BA1Q2 initiates call oompletton with matrix 
swir£hAB106. In one embodiinem,dti8 is aooomplished by sending a request 
to oonq[)lete die call to matrix switch AB106 via host gateway BAUO where 
required. Also, In a step DUI8, CMP BAICQ instructs CRD BA106 to free 
die operator console ABIOS from die call. This allows diat operuor Qonsole 
ABIOS to handle other calls. 

In a step DL322, CMP BAI02 sends a response to die operator console 
ABIOS Indicating diat die call can be completed. 
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2.2.9 (MT^m^figrfifmaBCpmmtBrCpamk 

The manner in which t call is tiBufemd from an opcfator oomole 
AB108 it now deacribed. Ftg. 49 is an openuional flow di«gnm illutoat^ 
call transfer from an opeiator AP108. Referring now to Pig. 49, when an 
opeialorAB108tiansfersacall«itsendsaieqoesttDCMPBAlffi^ Sitnarions 
in which a call h transfemd could be a tiansfer ftom a VRU Afil34 lo a 
mamial openuor ccmsole AB132^ or a tiansfer fhim a mamad ope^^ 
AB132 ID a customer service conscdeAB136. ]nasttpDL404«CMPBAlQ2 
leceives the lefpiest to tnuufer the call ftom tjpeiator console ABIOg. 

Becanse the call is being transfemd to another cpemor console 
AB108, a new opentor console AB108 must be allocaied. Thmfore, in a 
step DL40g, CMP BAlOl sends an alkicaie console mesa«e BA310toCRD 
BA106. In ie8ponse.aU>BA106eiandoBS a console usage l8bleBA374 to 
detrniine whfeh opetator consoles ABlOB are availsble sd handle the 
transferred call. When allocaied, in a step DL412, CMP BAIQ2 sends a 
regittst to matrix switch AB106 to transfer die call. In one embodiment, diis 
is accomplished by sending a message to host giuciway BAUO which in turn 
sends an PAR message to matrix swhch AB106 lo tiansfer the call. 

In a step DU16, CMP BAIOZ updates BIR EE322 in billing scrw 
BAIOS. In a step DU20. CMP BA102 delelBS die QC in mu^ serwr 
BA108 for die circuit to die requesting opeiator console AB108. 

In a step DL424, CMP BA1Q2 send) a message to CRD BA106 to free 
dieopenUoroonsoleABlOS originally allocated to handle die call. In a step 
DL428, CMP BA104 responds to die lequesdng console AB108 die transfer 
is completed. 
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2.3 BOUigSvHr 

2.3.1 BmigSimrbamdtuthi^ 

Tbe BSRVR BAIOB has Ave main functioiis. Tte fint function of 
BSRVRBAlWisiDlioldallinfoniiationonacallcurre^ This 
isaoooniplislied by asngnios every new call a unique callhandle to idemify the 
caU. 

The aeocNMl main function of BSRVR BA108 ii to dme the connected 
adl while it is in progress. 

The third main function of BSRVR BA108 is to infitmn the Real Time 
Fraud Detection and Prevention System (A0112) the time at which a call is 
ataited and die time at vriddi retail timiog is stopped. The real dme fraud 
dttection and preventicm system (A01i2) is also periodically updated on calls 
which last an unusually long time. 

The fourth main funcdon of BSRVR BA108 is to lceq> tnd( of the ctf^ 
duration fbr all usage cap Qpe calls, such as debit card calls, wluch are 
cunendy beliig timed for retail billing. When a warning period or maximum 
time is reached, CMP BA1(Q is notified. 

The fifth main function of BSRVR BA 108 is to transfer a BIR (EB322) 
of the con^teted call to die Billing System AO108. 

Measures can be implememed to insure tiiat no loss of data occurs. 
These measures include multiple Bill{i« Servers and locally Icept BIR files for 
redundancy. 
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BSRVRBAlOgbmwdetcrifaedwMiiete^^ 
which hintertees. Fig.SObablockdiitgnmiUuttatiotgtheGra^Ki^^ 
oommunlcaiB with one anodwr in nonnal operatkm of BSR VR BA108. 

Referring now to Fig. S0« A aeoondary BSRVR BAIOBB it pravided 
S as « badoip lo a primary BSRVR BA108A. This provides ndundancy* In 

one embodiment, die result of eveiy messige aett to primaiy BW 
is mirrored in seoondaiy BSRVR BAi(»B. Addidonally. die resnlt of 
messase trafRc internal to primaiy BSRVR BAIOSA, and all writes lo files 
and tables internal to primary BSRVR BAKNA are mirrared in aeoondary 
10 BSRVR BAIOBB. 

A high-level operational oonoept of BSRVR BA108 is now described. 
Fig. 51 is a data flow diagcam illustredt^ messages sett durii^ BSRVR 
BAIOS operations. Fig. 52 is an operational flow diagram ilhistradi« die 
piocess fEdlowed by BSRVR BA108 when a call U received by call imioessa^ 
15 system AB102. Referring now to Rgs. 51 and 52. In a step EE4QZ, BSRVR 

BA108 receives a callhandle request message BA3M ftm CMP BA102, 

In a step E£40i, BSRVR BAI08 assigns a callhandle BA3Q5 to d» 
call. In one embodiment, dits is aooomplished by incremendog die bst call 
ID by one and ORing (Boolean) dds value widk die value of an NCPID EG126 
20 and die BSRVRID Eai24 OHusttated in Fig. 55). 

In a ^ EE406. BSRVR BAltt otaies a BIR EE322 for die call. 
BIR EE322 is used to teilitate die real-time rating service and rcal-tiroe 
billii^ service discussed in didr two respective sections <rf diis document 

In a step EE412, BSRVR BA108 sends calthamUe BA305 tt> CMP 
25 BA1Q2. 
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A iq^reaeittative aichitectute of BSRVR BA108 will now bepitMsnttd 
and described. It shouU be mMed that diU ftrchitcctuit te pme^ 
of oample ocdy and ia not intended to limit BSRVR BA108 to tUs 
embodimenL Numerous alternative aichHectuies could be choeen to 
implemem BSRVR BAt08. 

Fig. S3 Is a bkick diagnm iUustndng die diite nu^ components of 
BSRVR BALOB aoootdii« to one embodiment Fig. S4 is a block diagnun 
niustcadog the billing aicUtecture of BSRVR BA108 in one emftxidlment 
Refenrii« now to Pigs. S3 and S4. BSRVR BAiOB oompiim dune main 
Gonqionentt. These am procedure kernels BMQ2, BSRVR files BA104, and 
BSRVR memory BA106. 

In one embodiment diere are ten procedure kernels EA102, four billlQg 
server files BA104« and fiour billing server memories EA106, as Illustrated in 
Rg.54. 

i.JLl.i BIBbig Sm$r PUn 

Turning now to Pig. S4, billii« server files EA104 are now briefly 
described* 

Gallhandle file EB142 is used to store a sirigle instance of die roost 
recendy assigned callhandle BA3QS. Gallhandle file BB142 is maintained so 
ttiat each BSRVR BA108 can assign a uiuipie callhandle BA3QS to each call. 
To gusnuitee diat callhandles assigned are unique, die most recendy assigned 
callhandle BA3(K is msiniained in callhandle file EB142. Callhandle file 
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EB142 U updued when each new calUumdIe BA3QS it an^gned and when 
BSRVR BA108 b riiut down. Upon lesiart of BSRVR BA108« die nmt 
reoendy anigned callhandle BA3QS is read fmm calUiandle Hie rai42. 

Gallhandle BA3QS Is a unique data tag given to eveiy new call that Is 
S itarted. No two calls ever have die same callhandle AA3QS. In one 

emhodiroent, callhandk BA3QS Is 32-bits In leivh. Fig. 55 lllustiates die 
structuitofcallhandleBASQS in diis embodiment Refening now to Fig. 55, 
callhandle BASQSoompriaesdiite fields. A fim fiekl Is a 27-tnt inciemental 
counter EO102tfiat u used to uniqudy identify callhandle BA3Q5. Forcacfa 
10 new callhandle thXtt assigned, incremental counter E0102 Is Incrememed 

hy one. In diis manner, each callhandle BA3Q5 assigned is uniqiie. 

One bit of callhandle BA3Q5 is designsteri as a blltlag server ID 
E0124. Bitlii« server ID EG124 Indicain v^ich BSRVR BA108 (for 
example, primary BSRVR BA108A or redundant BSRVR BA108B) assigned 
15 dUs particular callhandle BA3QS to the call. 

An NCP ID fidd EG126 is used to idendfy die NCP AB1(Q dut 
assigned die callhandle BA3Q5. Thus in call praoessiQg systems implemenied 
widi muldple NCPs ABICQ, die originatiGn of each callhandle BA3QS can be 
traced to a single NCP ABICB. 



20 2.3.2.L2 BiRFIk 

Tte purpose of RIR file EB 144 is to act as a bufier for all BIRs EE322 
ma to billing system AGIOS. 
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A representative Unicture of BIR file BB144 tDoneenUxidinieiit is now 
described. Pig. 56 is a diagnun illustrating the structure of BIR file BB144 
in one cndKidinient. 

Turai!^ now to Fig. S6, tlie fifst icooid of the BiR Pile BBi44 
cotttains a lieader £0202 ooittaiidng infbnnadon such as liow many reooids 
can be itept in BIR file EB144, currem number in die file, die poaidoo to last 
one inserted, and die number of reooids cunendy waiting tor le^Nmaes fram 
biUing ayatero AGIOS. BIR File EB144 is a circular file and (Hder BIRs are 
eventually Ofverwritten by new URs. 

When die Billing Server is started, die BIR nie is scanned and ail 
records dial are martoed widdng for responses are copied into die BIR Sack 
file for retry to billing ^stem AGIOS. This Is to insure dial all BIRs will be 
reiBd and die call MUed. 



X3^U Ba Stack PIb 

BIR stick file BB146 is a temporary stmage location for all BIRs 
EE322 dm were unsuccessfully sent to billing system AGIOS. 

Prsnd queue file EB148 temporarily holds all fraud requests when diey 
are unsuccessfully sem to fraud detection and prevendon system (AGl 12). 

2.3.2.2 Proadnm 

The tmportam procedures EAia2 of BSRVR BA108 are now 
described. 
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2.3.2.2.1 Main Root fwcedun Kgmgl 

Main root procedure kernel EB1Q2 is mponsible fiar sianiqg BSRVR 
BA108. The operadcm followed by nuin root piooeduie kernel EB1Q2 it now 
deacribed. Fig. 58 is an opmtional flow diapim iilustntii^ the itq» 
followed by main root procedure kernel EB1Q2 during start-up, operation and 
cleanup of BSRVRBA108. 

Refierring now to Figs. 54 and 58, in a step fiC102. main root 
procedure kemei EB1Q2 initiaUaes the reniaininig procedure kernels EA102. 
The procedure kernels EA102 initialLEed are a diem intertee (CUF) 
procedure kernel EB104, a log procedure kernel EB106, an update mirror 
pncedure kerne) EB108, a Receive Procedure kemd EBHO. a send BIR 
procedure kernel EB112, a BIR stack procednre kernel EBI14, a watchdog 
procedure kernel £6116, a debit procedure kernel EB118, and a fiand 
procedure kernel EB120. 

Inastep EC104, main root procedure kernel EA 102 allocates a portion 
of shared memory (reference number) for itself as billing server memory 
BA106. In diis step, main nxA procedure kernel EB1Q2 also initializes 
BSRVR BA108 call stats. In one embodiment, call statistics are imtialind to 
aero. Several call stasdcs are kept in shared mmory. These can include the 
ttMal number of BIRs EE322 successfully sem to billing system AGIOS, the 
currcm number of BIRs EE322 in BIR stack file EB106, the total number of 
reoriginatkins, and the number of calls currendy being timed. 

In a step ECt06, mun root procedure kernel EB1Q2 sets gtobal time 
variables to show the current time zone and any offset from Greenwich Mean 
Time (GMT). 
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In a step EC108, nudn root procedure kemd BBIOZ citstes tiid 
inidaliaes die needed tables in bitling wver memoiy EA106. These laUes 
include a callhandle table EB132, a console table EB134, a debit tabk BB136, 
andacall track table BB138. 

S In a sttp ECHO, inidn root procedure kernel BB1Q2 creates and/or 

Mtialues bniing server files BM04. These files Include a callhandle file 
EB142, a BIR file EB144, a BIR stadc file EB146, and a ftaud queue file 

The above-described steps EB102 through ECHO are the steps that 
to main root procedure kernel EB102 fbUows in creating BSRVR BA108. In 

opeiatlon, midn root procedure kemd BB1Q2 diecks BIR file BB144 for any 
reoocds to which there has not been a response. ThisoccunlnastepECll2. 
If any BIR records EB322 have not been responded to, these BIR rsoords are 
oopted ID BIR stack file EB146 for later transmission to billing system AGIOS. 
IS This occurs in a step BCl 14. 

In a step EC116, main root procedure kernel EB102 continues until a 
request to end the pn)gnan is received fnmi a user or from the s^ The 
most important fimcdondurii^ thiskxiping is to chedc a message queue in the 
procedure kernel. If a message is in message queue, it is passed to die 
20 appropriate procedure kernel far processnig. 

When a request to end the program is detected, main root procedure 
kernel EB1Q2 is responsible for cleanup operations. These are Illustrated in 
steps ECUS through EC226. In a step BC118, nudn root procedure kernel 
EB102 posts a message to trm box AG104 indicating the reason die 
2S applicatkm was terminated, in a step EC220, main root procedure kernel 

EBiQ2 dears a server m. memory. Server stat memory Is shared system 
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memory wiiich can be looesied by both BSKVR BA108 and lerver immilDr 
FA212 and uied to oommunicaie piooess status (illumted in Fig. 69). 

In a siep EC222, main toot prooedine kemd EB102 leturns shand 
memoiy to call proceasiqg system AB1Q2 for uie by other processes. 

5 In a step BC224« main root prooeduie kernel EBIOS saves the moit 

teoemcal]liandleBA3Q5loca]lhandlefi!eBBlC!. This is done ao that when 
BSRVR BA108 fs restarted, assignment of a unique caJlhandle BA3QS to an 
Incoming call can be performed in sequence from where the last assjgnmert 
wasmsde. 

10 In a step EC226, procedure kernels EA102 are deactivued. 

1.3.12.2 CSZmI im$mfke€ (CUP) Proetimn 

CUF procedure BB104 is ctcated by main root procedure kernel 
EBIQ2. When created, CUF procedure EB104 searches for a cmfigttntkm 
file SA404 (Ulusmted on Fig. 137). If this configuradon is not found, 

15 BSRVRBAI0BlGfisanern»rtoenrorboxAai04andexits. Otherwise, CUF 

procedun EB104 runs in the background* CUF EBIM mbles odier 
procedure kernels EA1Q2 to send tequestt over LAN BA122 and receive 
re^wnses frmn LAN BA122. CUF procedure EB104 U described in more 
detail hitheaiemlnterfoce Section of tfaisdocument CUF procedure BB104 

20 is not neoesnrily unique to BSRVR BA108. 

Log procedure EB106 sends a login message to log box AG106. This 
occurs when log procedure EB106 is created. 

Also at ifdtialization, log procedure EB106 routers widi CUF 
procedure EB104 to receive a billing server terminate message. 

1462.0010000 



I 



When log prooediue EB106 nceives lenninatB inesi«ge« a logout 
request is lent tt> log booi AQ106 on LAN BA122. 

Tlie login measi^ oontains the time at which the anilication was 
started, the name of Oe application, and the version mimber. The logout 
message oomains the time at which the application was terminated, the name 
of the appltcaticm, and the version number. 

2.3.2.2.3 Up^ Mimr Pmetdmn 

Update mirror procedure BB108 is used to help keep both primary 
billii^ server BBIOS and secondary billing server EB108 redundancy 
infisrmation and statuses Identical. Upon InitialbEation, update minor 
procedure BB108 registers with CLIP procedure BBlOi to receive a PUT 
message BD228, a mirror message, and a UP messige. 

UP message indicates to update mirror prooeduie BB108 that die 
redundant BSRVR BA108B Is running and requesting all current call stams 
infiDrmatson. When update minor procedure EB108 receives UP message, it 
searches callhandle table EB132. For every currem slanis found In callhandle 
table BB132, update mirror procedure EBI08 sends a PUT message to 
redundant BSRVR BA108B to update minor procedure EBIOS in the 
nsdundant BSRVR BAIOSB. This action ensures that data In bodi BSRVRs 
BAiOSA and BA108B are redundant. 

When update mirror procedure BBIOS of redundant BSRVR BA108B 
reodves PUT message, it sear^ callhandle table BB132 of redundant 
BSRVR BA108B to see if the sotus infmnation is there* If the stadis 
information is diere, it is updaied. If the status information is not in 
callhandle table EB132, it is added. 
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Duiiqg nonna] operattonSi the minor msmgt is lent fhiiii primaiy 
BSRVR BA108A to redundant BSRVR BAIOSB. Minor men^ cames 
redundant BSRVR BA108B to perfonn the same updates to WMtig server files 
EA104 and Ulliqg server memory EA106 as is performed by primary KRVR 
BAIOSA. HiL mures that tedundam BSRVR BAIORB is compleieiy 
redundant with primaiy BSRVR BAIOSA durii^ normal qmiiou. 

Receive Procedure EBllO receives aU messages cmntiig from CMP 
BAIQZ. The manner in which Receive Procedure BBllO opemes will now 
he described. Fig. 60 is a dam flow diagram ilhisMiic data flow hetween 
Receive Procedure EBllO, procedure iomels EA1Q2« billing server files 
BA104, and WlUi^ server memory EA106. 

Referring now to Figs. 60. S4« and 14, die operation of Receive 
Procedure EBllO m\\ now be described. This desciqition is provided in 
terms of an example. This isaneiuunpleof dieaperBiiimsperfbrnied vdien 
BSRVR BA108 receives a GET CALUMNIU RSQUEST MESSAGE 
BA304 from CMP BAia2. Fig. 61 is an operetkmal flow duigram illustrstiiig 
die manner In which a receive process responds to a GET CALUOANDLE 
RBQUEffT MESSAGB BAJ04 fnm CMP BAia2. 

In a sttp EK1Q2, BSRVR BA108 receives GET CALUBANDLE 
REQUEST MENAGE BA304 from CMP BA102. More specifically. 
Receive Procedure EBllO recdves GET CALLBIANDLE REQUEST 
MESSAGE BA304. As described above, GET CALUANDUK REQUEST 
MESSAGE BA304 is a request from CMP BA102 toas^gn anew callhandle 
BA3QS to a new call. 
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In I «ep BKIIM. Receive Praoedura BBllO woews calUiamile file 
BB142 lobiiiki ■ new ctOhandle BA3Q5. 

InasttpBKlCtf, Reodve Pracscdure BBl 10 updatncaltttttidle memory 
EB132 with tbc latest callhandle BA305 reeved. Requnt messagm received 
by BSRVR BA108 may include a callhandle BA3QS referencing the call for 
which die request is made. To emdile handling a Ugh number of roesngDS 
and to provide npteA when kiddng up call infbnnation using a callhandle 
BA3QS. callhandle table EB132 is udlLmd. 

Callhandle table BB132 is a table diat stores callhandles BA3Q5 for 
eachcali. Callhandle BA3Q5 stored in callhandle table BBi32 la a pmnier to 
a ston^locatkm for inftmnation about the call. Callhandle BA3Q5 Is stored 
in callhandle table BBI32 as illiotratBd in Pig. 54. EMfa callhandle BA3Q5 
points 10 stooge locatlcnis for call infimnation, die BIR BE322of ihecall, the 
call circuits, and a device amy for die call. When it Is desired to find such 
information for a call, die callhandle BA3Q5 for dnt call is found in callhandle 
ndile EB132. When a request for call information is made, die callhandle 
BA305 for diat call is found in callhandle table EB132. When die callhandle 
BA30S for die call is found, die pdnter to dte call data (to example, die 
pcrinter to die BIR EB322 for duU call) Is found and te&imed. 

In a step EKIOB, Receive Procedure rauO updates console table 
EB134 widi a CONSOLE UPDATE MESSAGE EH 122. Console table 
EB134 stores call stanis information imtexed by console number versus 
callhandle BA3QS. Because valid console number ruiges are known, simple 
variable armys can be used. WhenaconsolenumberEHlli is received, it 
is entered into console table EB134. Console table EB134 can be updated 
every time a MODIFY BIR MESSAGE DQ1Q2 is received from CMP 
BA102. This occurs udien a call is routed to an operator console AB108. 
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When i call is routed lo Che teminatiiv uier AA106. a START 
BILLING MESSAGE EH126 \n teat bom CMP BAI(Q to BSRVR BA108. 
In a fllep EKUO» Receive Procedure EBllO receives START BILLING 
MESSAGE EH126. START BILLING MESSAGE EH126 contains the 

5 caJlhandle BA30S of the call to be timed. F^g. 61 is an operational flow 

diagnm illustrating what occurs when Recdve Procedure reodvea START 
BILLINGMESSAGBEH126instBpBKilOofFig. 61. Refenii«nawiD 
Fig. 62, in a step BL1Q2, calOiandle BA3Q5 for die call Is looked up in 
callhandk table EB132. If callhandle BA3(tf is not found (decision blodc 

10 EL104), an error message is amt to mor boa AGt04 indicating that 

calttaodle BA30S does not exist for the call. This ocean in a step EL106. 
The partner (secmdaiy biiling server BAIOSB) is dien asked if it has the call 
sianis rdated to die callhandle BA305 in question. If so, die infbrmation is 
passed back to die primary BSRVR BA108A. TUa occurs in a step EL1Q7. 

IS In a step EL108, a call status Is added. A call status is a structure 

containii« the BIR BE322 as an element aloqg widi odier call information 
such as currem console number, number of dtcuits being used, device types, 
and dreuits bdng used. When a BIR EE122 is aUocamd fur a can, a call 
status (i.e., a dreult identification code) Is alao allocatei. 

20 If,ondieod»rhawl,callhandteBA3a5i8foundferdiecdl(decisk^ 
bkxdc EL1(M), a BIR pdnter rai62 oorrespondii« to die callhandte BA3U 
for die can, is read to indicate whMi BIR (EB322)beioi|gs to die call. This 
occun faia step BLllO. 

lnastBpEL112, BIRBB322fardiecalllsdm&-Aamped. Hie time 
2S stamp signifies when a call has been connecred and Wllhig of user AA 106 is 

to begin. 
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Referrif^ agtf n to Fig. 61, In a step BKl 12, Receive Procedure BBllO 
mds a STAItT4>FCAlX MESSAGE CUusti^ in Ftg. 175) to the fnod 
detecticMi and prevemion system AGl 12. The purpose of START-OF-CAIXi 
MESSAGE is Mly discussed in the Fraud System Section of diis documem. 

When the call Is fiirished (when one of users AA106 hangs up). 
Receive Procedure Kernel receives a STOP TIMING MBSSACSE EH130 
whfch initiaies die send BIR procedure kernel EB112 to send die BIR BB322 
assodated with die call. The Receive Procedure Kernel sends a STOP CIAIX. 
MESSAGE BH 128 to dw fraud system widi the response being handled l»y die 
ftaud procedure. 

The process followed by send BIR Procedure Kernel BB112 will now 
bedeacribed. Pig. 63 is an operadonai flow dtagiam lllustiatlng die process 
diat oocun when send BIR Procedure Kernel EB112 receives stop dmii^ 
messageEHlSOseminstepBKlUof Pig. 61. R^rring now to Fig. 63, in 
a step EM102, callhandle BA3Q5 fbr the call is loolced up in callhandte table 
EB132. 

If callhandle BA3QS is found (dedmm blodc EM104), die opersdon 
oondnues at fiep EMllO. If, on the odier hand, callhandle BA3Q5 is not 
found for die call (dectsi<m block EM104), send BIR procedure kemd BB112 
sends an error message to error box AG104. This occurs in a step M106. 
Once the error message is dispatched, a request is made to die secondary 
BSRVR BAIOB for all die infmwdon it has passed regarding die callhandle 
BA305. This occurs in a step BM107. In a step EM 108, if callhandle BA3QS 
Is not found for die ctf , a callhandle BA3Q5 is added in a step BM108. 

In a step BMllO, send BIR procedure kernel EB112 determines 
whedier a flush flag EH164 is set. If flush flag EH164 ts set, in a step 
EM 112, BIR EE322 Is flushed. 
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If flush fl«g BH 164 b HOC set, lend BIR piDcedtue kmei BBl 12 met 
cbeclciinasiq»EMn4(bra vaiidtiniestunp. If die tbnestenip b valid.* 
dundan for the call it oompuied in a step EM116. In a step EM118, BIR 
EE322 is updated to leflect die duiatkm of die call as computed in step 
EM116. 

In a stq) BM120, die updated BIR BE322 is stored in a BIR file 

BB146. 

In a s(qi EM122. BIR EE322 is bent to billing system AGIOS. 

The process of snp EM122 is fimher described wtdi lefeience to I^. 
64. Fig. 64 is an opeiadonal flow diagram illustiatiitt the pioom of sendi^ 
BIR EB322 to billing system AGIU. Refeirii^ now to 1%. 64, in a step 
BPl(n. BIR BB322 is sent to billii« system AG108. 

If the billiog system AGIOS is busy or inactive, BIR EE322 is stored 
in BIR stack file EBI46. BIR stack file EB146 b a flat file used to sunt BIRs 
EE322 diat oould not be sent to billing system AGIOS. 

lnastepEK]16, once the stack timer has expired. Receive Piooedure 
kernel EBllO sends a BIR CHECK MESSAGE EH132 to BIR stack 
pn)oedure kernel EB114. In response* BIR smck procedure kemrJ EB114 
checks BIR stack file EB 1 46 to determine whedier there are any BIRs EB322 
diat have not been sent to billing system AGIOS. Thb occurs as described 
betow in a step ERI02. 

The process diat occurs when BIR OIECK MESSAGE EH132 is 
received by BIR stack procedure kernel EB114 will now be described. Fig. 
6S u an opersdonal How diagram illustretiqg die process diat occurs in 
re^nse to BIR CHECK MESSAGE EH132. 
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In a Step BR102, BIR stack piooeduie kernel BBl 14 checks BIR stsck 
fiteEB146 to deteminewfaedier there «rDinyBlRsEB322stor^ In 
odwrwoids, BIR stMk procedure kerndmiUdiecks to see if dm aieiny 
BIRs BB322 that send BIR piocedure kemet EB112 previouly tried to send 
S to billiiv lystem AGIOS. 

If e BIR BB322 is fiound (decision block ER104). it is retrieved from 
BIR stack file BB146 in a 8tq> BRIO& 

Ina stqi ERIOS, BIR EE322 retrieved in step BR106 is sent to send 
BIR procedure kernel EB1I2. in a step Oil 10, send BIR procedure keniel 
10 EBI 12 attempts to icsend BIR EE322 to billii^ system AGIOS. 

The Send BIR procedure is where all responses to requests to the 
billing system AGIOS are processed. During operstion of the Billing Server, 
many requests are made to the billing sytiem AGIOS. Each request is maiked 
IS to determine if all calDiandle infDrmadon can be removed when ttie request 

comes back. If a request to the billing i^stm AGIOS fails, the BIR will be 
written to the BIR Stack file for retrying later. 

2.3.2.2.5 BIR Stmt Fn>c€dun 

The BIR Stad: procedure is respon^le for re-sending BIRs to billing 
20 system AGIOS. This procedure makes use of the BIR Stack file described in 

earlier sections. At initialization, a timer Is started. Each time die timer goes 
off, the BIR Stack file is checked for BIRs to be re-sent to die Billii« system 
AGIOS. 
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If a BIR 15 found in the file, it is rMent. When a suooestful mpont 
comes back, the file is chedced for the neat one to send. If dieie are no 
further BlRs to re-send, the file is truncated. 

mObgSunrTgUa 

BSRVR BA108 has munerous tables asBodated with it Some of these 
tables are now described. 

As described below with reference to F|gs. 66 and 67, most requests 
come to die BilUog Server with the callhandleBA3Q5 of tiie call. Becanseof 
the potential high number of call statuses and the speed denied in perfonnii^ 
look-ups based m callhandle BA3Q5, a hash taUe is utiliied in one 
embodiment All information on a call is Inpt in a record m memory. A 
pointer to this memory is then kept in die callhandle hash table. 

During a search for callhandle infimnatioo, the callhandle BA3Q5 is 
sorted and the link list is traversed to find the maichnig callhandle BA3QS. 
When found, the pointer to the call status stm^ure is relumed. 

Comb Tatin 

Although most requests involve findlqg call stams information for a call 
identified by a callhandle BA3QS, acmic reque^ lequiR Hm the information 
be found usir« a console number. Because valid VRU AB134 and MOC 
AB132 number nu^ are known, simple variable arrays can be used for this 
table. When a console number is received arKl needs to be tied to a callhandle 
BA30S for tater use, an entry In mie of two tables is made. 
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Prom the known amiole the contct able to de te r m ined. Next, 
if die oonsole nuiriber ii beyond the am^, the table Is increaied to allow 
indeaii^. Only a pdnter to die Callhandle HaA table b kept. 

DdHTMu 

Widi deUt caid caila, it b desirtble dutt die call in piogren be 
oonrtantly monitored for two reaaoas. Pint. itbdednMelowaraorisiQadiig 
uaer AAIOM when die lengdi of die call hu almost exceeded die bnlanoe of 
tbecaid. The aeoond tcaaon iaao die call can be trniinafiad when die call bas 
met or exceeded tbe balance of the caid. lo one embodiment, thb b 
fimcdonaHty to accomplished muMple debh caida whkh are dmuli^^ 
in use by ptadng die spedfic debit caid informadon in a aqiarate linked list 
fiom die actual B1REE322 in die calttiandlehadi table for die call. Scanning 
dds list ODoe cwenf aeoond idkiwa dw lystem ID nodfy die oiiginator wh« 
mqidied in a droely mannv . The debit tiMe entries are linked to die BIR 
EB322 for die spenfk: call by die calthandle BA3Q5 and BIR identification 
number. 

2,311.3.4 Off TmddMg Mit 

All calls, whedier connected to a particular device (VRU Afil34, 
Manual Opemor Qmsole AB132, Vcrice Mall, etc) or completed to a 
teminadng number, have an aMoclated BIR EB322 and an entry in a Call 
Traddng table. Thb table helps die BSRVR BA108 to identify BIRa which 
should be aem to l^lii^ system AO108 but have not been aem for aome 
reason. 
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13.4 IMmtStuuf 

Redundancy is an extremdy impoitam criteria of the BUlii« Server. 
If calls are in pfogress and the bUltng infbnBalkm fat the calls is lost, revenue 
is lost also. To prevent this potential problem, die Billing Server is Ktually 
a pair of identical piognms. One is die prinaary; die other is the secondary. 
They are refiBrved to In dils document as "partners.' Aity time one partner 
adds a callhandle, updates any infbnmiion dealing whh it, die tdendcal 
information is iQxIated to die partner. At ai^ time both partners should have 
idendcai tables in memory. 

1JL5 mUag^Calb 

One function of BSRVR BA108 is to perform wholesale and mil 
timing ofa call for billing purposes. BSRVR BA108 uses BIRBB322 to keep 
tnck of start and stop times so tint call durations can be computed and 
forwarded to trilling system AGIOS for billing purposes. 

The manner In which BSRVR BA108 detemdnes start and mp times 
for a call is now described. Fig. 66 is an operstional flow diagram lihisirating 
die process by which BSRVR BA108 trades die start time of a call. Referring 
now to Pig. 66, in a step ET104, BSRVR BA108 receives a stan timing 
message from CMP BA102. CMP BAIOZ generates and sends dsis message 
to BSRVR BA108 when the call is answered by die called par^. 

In a stq> ETIOS, when BSRVR BAIOS reodves die start timing 
message from CMP BAIOZ, BSRVR BAIW retrieves die BIR EE322 
associated whh die call. The identification of die correct BIR EB322 is made 
using die callhandle BA305 assigned to die call when it first entered call 
procesring system AB1Q2. When BIR EE322 associated widi die call is 
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toctfed, It It iqpdatBd Co indicate thtt the call is connected to the destination. 
This oocun in step ETUO. 

In a step Ern2. a retail connect time field in die BIR EE322 fDr the 
call is aet to die cunent system time. Similarly, in a step BT1I6, the 
wholesale connect time field In dte BIR EE322 associated with the call is aet 
to die cunent astern time. 

Upon perfbrmii« diese steps, BSRVR BA108 updates die BIR BB322 
associated widi die call to include die actual times diat die call was couneetBd 
to die tOTiinatii^ taer AAlOffi. In a step ET120, a call started message is 
sem to taud detection and pievention system AQl 12. This message is used 
by ftaud detection and ptevention system AG112 to monitor calla fbr die 
puipose of detectii^ possible fraudulent use of call prooessitig system ABIOZ. 

Todeterminedwdumtionof die call, die system must also know when 
die call was terminated. The process by which die tmination time of a call 
is determhied and tradced b now described. Pig. 67 Is an operational flow 
diagram illustiatif^ die process by which BSRVR BA108 updates die BIR 
EE322 for die call widi die teiminadon time of die call. 

Refening now to Fig. 67 Jn a step ET202, BSRVR BA108 receives 
a sup timing message fipom CMP BAKU. CMP BA 102 generates die scop 
dming message when eldter party hai^ up die phone or die call Is odierwise 
terminated. Upon receipt of die stop tirnh^ mesntge, BSRVR BA108 
retrieves die BIR EE322 associated widi die call. This occurs in a step 
mr206. BSRVR BA1(M retrieves die BIR BE322 based on die callhandle 
BA3QS diat was sem widi die atop timing message fhmi CMP BA1Q2. The 
callhandle BA3Q5 identifies die call and is used to identify die appropriate BIR 
BE322 dot corresponds to die call. 
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In a step ET210, BSRVR BA108 upditei die UR EE322 with the 
cunent syAon time. Thus, BIR BB322 now Includes the time at v^kh Oe 
call was cerminaiBd. 

For calls that were billed on a per-unit time tasis, it is imponam to 
calcufaUB the duiation of the call so that the proper biUii^ amoimt can be 
determined. Tlius, in a step Er212, BSRVR BA108 calcuhtes the wholesale 
and retail durations of the call The wholesale and retail durations can be 
calculated by subtrKdiig die wholesale and retail start times firom die stop 
time, respectively. 

In order to have die correct sort time appear on die subscriber's 
AA114 bill, it may be necessary to aiyust die start time to a different time 
zone. If diisisdiecase,dusisdoneinasfiBpET216. Now« die BIR EB322 
asaodated widi die call is oompleie wiA wholesale and imil san time and 
stop times far die call, and die wholesale and retail durations of die call. 
Thus, whoi BSRVR BAIOS sends BIR EE322 to bilUng system AGIOS, an 
appropriate bill can be generated and sem to the correct subscriber AA1I4. 

In a step Er220, BSRVR BA108 sends a call stop time message to 
fraud detectionand prevention system AOl 12. Fraud detection and prevention 
system AG112 uses die stop time in cox^juncdon wtdi die start time (sem in 
step ET120) to nnomior die network for poiemial fraudulent uae^ Thefiaud 
detection aivl prevention system AG112 is discussed in detail in die Raod 
System Section of dils document. 

In one embodiment, BSRVR BA108 sends a response to CMP BAIOQ 
indicating diat die timii^ of die call has been completed. 

Once die timii^ information for die call is convicted, as noted above, 
die BIR EE322 for die call is sem to billing systam AGIOS so diat die call can 
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be bilM. la one embodimem, ihii is ooordimtBd by CMP BA1Q2. When 
BIR EE322 is fully ufMbted, CMP BA102 sends t send BIR message to 
BSRVRBAIM. This is received by BSRVR BA108 in t step BT304. Pig. 
68 is an opmtional flow diagnun lllustntiQg the process by which BSRVR 
BAiW sends a BIR BB322 lo billii« system AGKM, 

In a step ET306, BSRVR BA 108 retrieves the BIR BB322 for the call. 
Once again, this is aooompltshed usiqg a callhandle BA3QS asso dat ed with the 
call. Callhandle BA305 is sem by CMP BA102 with the send BIR message. 

In a step BT310, once BSRVR BA108 hu cetrieved die BIR BB322 for 
the call, it sends die BIR EB322 to bUUi« system AGIOS. 



1.4 DaMu9 S0rm(DBS) 

NCP AB104 uses a DBS BA104 to access aeveml databases. DBS 
BA104 performs functions, or services, for NCP AB104 in response to 
messages received over LAN BA122. For example. DBS BA104 mrieves call 
panmeters BA308 in response to a GET CALL ID MESSAGE BA306 
received fhmi CMP BA102. 

The functionality of DBS BAI04 is <lescribed at a high level in die 
Network Control Processor Section of ttiis document. DBS BA104, its 
oonfigutation in a prefoned embodiment, and its opemion is now described 
in greater detail. 

Fig. 69 is a blocic diagnm illustrating DBS BAI04. Fig. 70 is an 
opemtional flow diagram illustrating a process by which DBS BA104 Is 
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created. Referrii^ now to Figs. 70 and 69, DBS flA104 tnterfHet id die 
other pvDoesses widiin NCP ABi04 via LAN BA122. in a Aq» FA102. a 
control pn)oess FA2Q2 is created. Control prooea FA202 imerfim to LAN 
BA122. 

In a step FA104, oontnri process FA202 reads a configuretion file 
FA204. 

in a step FAi06, control process FA2QZ creates a shared memory 
FA206. At the same time, control process PA202 creates a slats imess 
FA208. Stats process FA208 does not commiudcaie via LAN BA122. Bodi 
stats process FA208 and control process FA20Z can write data to shared 
memory FA206 and read data from riiaied mcmmy FA206. 

These elements, control process FATOZ, con^guiation file PA204, 
shared memory FAW, and stats process FA208, make up a basic database 
server. In a pnefened embodiment, whenever a DBS BA104 is created, it 
ahvays has these baste components. These components are piesem regardless 
of die file structure diat DBS BA104 may have, or whedier any files exist at 
all. 

Configuiation file FA204 includes a services list FA209. This services 
list FA209 Includes a list of services FA210 dat perform the functions 
required of DBS BA104. Services Hat FA209 ah» includes a list of die 
databases FA2 14 diat DBS BA 1 04 can access when responding to a message. 

A service FA210 is umply a progiam or process started by DBS 
BA104. In a preferred embodimem, most services FA2tO have one or more 
databases FA214associasedwidi diem. Hofwever, there is no reguiremem thai 
each service FA210 have a database FA214 assodated dierewidi. 
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In a Step PA108, oontiol process FA202 aooessts oonfigitmkin file 
FA204 to read seivioes list FA209. 

In a Step FAl 10, DBS BA104 Cfcates all of the services FA210 listed 
in list of services FA208. Services PA210 communicate via LAN BA122. 
S Services FA210 all access shared memoiy FA206. 

A server momtor FA2I2 imerftces via LAN BA122, and is used to 
momtDT the DBSs BA104 operttiqg. Server moidtor PA212 is started 
independently of omtrol process FA2a2 and Htm balance of DBS BA104. 
Server roooitor FA2I2 monitors d» emire DBS BA104 by communicadng 
10 widi control process FAIQZ. Server monitor FA212 does not communicaie 

(Urectly with any m service FA210. Server monitm- FA212 can monitor 
eadi of ttme services through control process FA2Q2. DBS BA104 can be 
used to start up and shut down NCP BAI04. 

As noted above, services FA210 can have an associated daisbase 
15 FA214. Wh^ber database PA214 ousts for a service FA210 depends on the 

particular service FA210. Examples of services FA210 include a CALL ID 
SERVICE FA210A and a NUMBER TRANSLATICm SERVICE FA210B. 

The DBS BAi04 iHustrased in Fig. 69 is a server that can ran in a 
UNIX or an OS^ environment, for example. In these environments, multiple 
20 services FA210 can each run as multiple plications. InaDOSenvinmnwnt, 

multiple applications cannot be run simultaneuusly; however, services PA210 
can perform multiple Amctions timultaneously. 

An exanq>Ie of a service FA2I0 In DBS BA104 is where DBS BA104 
retrieves call paramelerB BA308 from a call ID database FA214A in response 
25 toGErrCALLIDR£QUESTMESSAGEBA306fromCMPBA102. Inthts 

example, GCTCAU. ID REQUEST MESSAGE BA306 has information in 
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a header portion indicating die identificattoa of die specilk sefvioe FA210 
requited. In diia case, a CALL ID SERVICE FAllOA ia idendfted. 

When GET CALL m REQUEST MESSAGE BA306 is received 
DBS BA104, CALL ID SERVICE FA210A aooeaes die call ID datafaue to 
retrieve call pammeten BA308. CALL ID SERVICE FA21QA dien places 
call parameten BA308 on LAN BA122 for transmismn to CMP BA102. 

An additioiml exanq>lo of a service FA210 is a number traasladoD 
service FA210B. In diis example, CMP BA102 sends a mess*^ requesting 
dotDBSBAKMtrenslatBanuRter. For eiain|^ CMP BA102 may request 
DBS BA104 to tmnslate an 800 nunter tnio a terminating teleplm 
In diis example, service PA210B reads die 800 number, and accesses an 
ai^ropriate 800 translation databsae FA2I4B to letrieve die translated number. 
The transkied number is dien sent to CMP BA102 over LAN BA122 as a 
leqionse message. Number tianslation is discussed folly in die Number 
Thuisiadon Sectitm of diis document. 

The following Tsble of Dstabase Services illustmtes by way of example 
a number of service FA210 diat can be provided by DBS BA104. 
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1 TABLE OF DATABASE SERVICES 




DB_OP_PROFILE 


DB_SCRIFr 


DB_HELP j 


DB^SUBSCRIBER 


DB NPA CITY 


DB_DEF 


DB_^VALID 


DB^CALUD 


DB_SPEBD_DIAL 


DB.LINKCARD 


DB>CCOUNT 


DB_COUNTRY 


DB_800^TRANSLATION 


DB.800.TERMINAT1ON 


DB.HOT/COLD 


DB^VAUNDEX 


DB_VALBLOCK 




DB^VSCRIPT 




DB^DEBTT 




DB_^DEBnBAT 




DB^ACCOUNT_CODE 




DB^Cn^CARD 


1 DB^VM56 




DB_VMBOX 




DB_VMACCESS 




DB_BNID 




VALIDATOR 


1 CRD 


1 ^ 
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An example of a lervioe PA210 without a daobaae PA214 ii a 
validation lyatem AGKB (illuitiated in Eg, 87). Validation syttem A0102 
does not have iu own databaaa FA214 but communicates with odwr services 
FA210 in validating calls. These other services FA210 may have their own 
databases to perform database bolc-ups where required. For example* an 
internal calling card verification service may have an assnctatcd datsbne for 
valid calling card numbers. 

The opendonal process by wluch DBS AA104 processes a message 
received over LAN BA122 is now described. Fig. 71, which comprises Figs. 
72 ami 73 Js an operational flow diagram illustiMtaig the stqps p er formed by 
DBSBA104whenaitttwoikmesni8eisiecdvedoverlANBA122. Fig. 74 
is a data flow diagtam illustrating die mesiages that flow to and from ras 
BA104 when processing a message. 

Refenring now to Pigs. 69« 72, and 74, in a step F&102, DBS BA104 
is active and monitoring LAN BA122. In this step, DBS BA104 is waiting for 
a necworir message FA222. An example of a netwoifc message FA222 is a 
GET CALL ID REQUEST MESSAGE BA306 soit from CMP BA102 to 
DBS BA104. 

In a step FB104, DBS BA104 recnves netimk message FC122. In 
a preferred embodimrat, netwoii message FC122 isapacket of data recnved 
over LAN BA122. 

When NETWORK MESSAOS FCm is tecdved. DBS BA104 first 
verifies the service name oomained in a header of NETWORK MESSAGE 
FC122 to determine whedicr the service name is correct This occurs in a 
step FB106. 
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If it » detmaiiiBd in itep PB106 ttiat the service name is Inoomct, 
DBS BA104 aeods an ERROR MESSAC» fl FBC224 to enor box A0104 
in a stop FB108. ERROR MESSAGE fl FEC224 indicates that a 
NETWORK MESSAGE PC 122 was itoeivcd with an inoomct aervloe name. 

If (he servtcse name isoonect, DBS BAI04 neitdeiennlnes whether the 
sizeof the packet reoeived is conect TUs oocura in a step FBIIO. Instep 
FBUO, DBS BA104 compsies the actual siie of the leoeived network message 
PC122 to die size tfttt received netwoik message PC122 is supposed to be, as 
indicalBd in die message header. If the siae is incorrect, in a step PB108 an 
ERROR MESSAGE 12 PC126 is sent to tsnar boa AG104. ERROR 
BffESSAGE 12 PC126 indicates dial the padtel to of the received message 
iainoorreet 

An example of when a padcet sin error may occur is when DBS 
BAI04 does not recdve the entire padcet 

It should be noted that these validatkms pvfbrmed in stqis FBl^ 
FB 1 10 are optional steps that are porfbrmed in a preferred embodinieitt. his 
not mandatoiydiat validation steps FB106 and FBI 10 be performed. Further, 
validation steps FB106 and FBilO can be performed in any dinmological 
otder. They do not have to be pcdbnned in the order iUustnted in Fig. 72. 

F6r validation steps FB106 and PBllO, if an error has occurred, the 
opeiation resumes at step FB102, where DBS BA104 is waiting for a network 
message PC122. 

if die packet size is correct as d^ermined in step FBllO, and die 
servke name is comet as determined in step FB106, DBS BA104 contimies 
at a step FB112. In step FB212, the service FA210 to which NETWORK 
MESSAGE FC122 is addressed, determines whether die message ID can be 

I462.0010000 



piooened. In other wordB» the de4givtediervkxPA210de^^ 
the action that NBTWOKK MESSA<» FC122 U iec|iie8tij« can be 
perfonned by that lervtee FA210. IfthemessigBlDcaiuiotbeimttued.an 
ERROR MESSAGE 13 PC128 ts sent to error box AG104 in a step FB214. 
ERROR MESSAGE §3 PC128 indlcatei that the requested functkn cannot 
be peiteined. 

If the function can be performed (in other woidt, if the mesiige 1^ 
be processed)* the designated service FA210 processes die ncsstite in step 
FB216. The received network message PC122 may oomnand die drwgnsfnri 
service FA210 to perform fonctions such as wntn to a reooidt delete a record, 
addarecord. Addidcmany, received NETWORK MBSSACT FC 122 may 
^raply be requesdqg a response from the service FA210 to determine whether 
service PA210 is active. 

If an error occurs m step FB216, an ERROR MESSAGE #4 FC130 
is sent to error bos AG104 indicating tfnt such an error occurred. ERROR 
MESSAGE #4 FCI30 is sent to error boa AO104 in a step PB218. 
Additionally, if an error ocpirred in step PB216, a response is sent to the 
process that originated d» recdvod network message FC122, indkating that 
an error has occurred. This re^xmse is sem in a step FB216. 

If no errors occur in processing itcrived NETWORK MESSA(X 
FC122, die apprapriate RESPONSE PCI9 is sem to requesting process 
FCIOZ tiwt sem received NETWORK MESSAGE PC122 to DBS BA104. 

Additionally, received NETWORK MESSAGE FC122 may be 
addressed to control process FA2()2. In tiits case, control process FA2Q2 
porforms steps FB212. FB214, and FB216 to process RECEIVED 
MESSAGEFC122. Examplesof functions diatcoukl be requested of control 
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prom PA2Q2 wilh received mmage FC122 ■» ad^ 
or deledns an existing service PA2 10. 

To better iUustntte (he functioinli^ of DBS BA104, these operational 
steps will be descrB)ed wtth itfetende to an eumpte leceived NBTWCHUC 
MESSAGE FC122 and RE^NSE M£SSA(» FC1». In diis example. 
CMP BA102 sendsaGET CALL ID REQUEST MESSAGE BA306 to DBS 
BA104. DBS BAlOi receives die GET CALL ID REQUEST BiESSA(» 
BA306insttpPB104. 

DBS &A104 verifies that the service name is valid in AepPB106. In 
this «ep, DBS BAI04 verifies that a CAUL ID SERVICE PA210A is an 
Ktive service PA210 within DBS BA104. lliis validadon is performed by 
ounool process PA2Q2. 

DBS BA104 next determines whedier die sin of the GET CAIX ID 
REQUEST MESSAGE BA306 received oonforms to the sise indicated in the 
message header. This is perCnmed in step FBUO. 

if eidier of these validations (steps PBI06. PBl 10) indicate dat there 
is an error, DBS BA104 sends die appropriate error messsge (ERROR 
MESSAGE fl PEC224, or ERROR MESSAGE 12 PC126) to error box 
AG104 in step PB108. DBS BA1(M then oontimies to monitor die tietworic in 
8iepPBlQ2. 

If diese validations do not Indicate an error, DBS BA104 next 
determines in step PBU2 whedier die GET CAIX ID MESSAGE BA306 can 
be processed. In dits step, CALL ID SERVICE PA210A loob at die 
funcdon requested by GET CAIX ID MESSAGE BA306 to determine 
whedier it can be p^formed. 
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If the fbncdon nquested by GET CALL ID MESSAGE BA306 cumo t 
be perfbrmed by CALL ID SERVICB PA21QA, ERK» MESSAGE #21 
PC128II lent to error box AG104 in tiepFB214. DBS BA104 then tendi i 
leapcmie FA224 to CMP BAI02, imticadflc thai fiinctian lequestDd li> 
5 GET CAIXmHBQUESrr MESSAGE BA306cinfiot be perfit^^ 

BA104 then mooitDn the netwoik in sicp FB102 wattipg for a new 
NETWORK MESSAGE PC122 to be received. 

\U in step FB212, CALL ID SERVICE PA2IQA determinea that the 
ftincdon can be perfornied« the opentlon oonthnies at atcp FB216. In step 
10 FB216. caU ID aervkae PA210A acceaaea call ID databaae FA214A to retrieve 

call paiameters B A308 requested by GET CALL ID MESS A(X BA306. 

If no errm occurred in this prooeas, DBS BA104 aendacall pafameten 
BA308«iCMPBAia2tR8lepPB216. Ifanmor <tidoociir hi8tq>FB216« 
DBS BA104 8end8areaponaeFA224toCMPBAia2 indicatii« dna the call 
15 panunetm BA308 cannot be mrieved. DBS BA104 additionally sends 

ERROR MESSAGE #4 FC130 10 error box AG104. 

X4L2 Pffrtfuf 0 Pirfttfir r f S9rfk$ 

To ensure efficient operadm of DBS BAI04. the capaUUly is provided 
to delete a aervloe FA210 if is it no kipger reqiured. Ttus alkiws unwanted 
20 services to be removed from DBS BA104. Deleting service PA210 lurdier 

allows the portion of shared memory PA206 dnt service FA210 uses to be 
made available for other uses. 

The process by wludi a service FA210 is ddeied is now deacribed. 
Fig. 75 is a data flow dlagnun illustrating the messages involved tn deleting 
25 a service FA2I0. 76 is an operatitmal flow chart illttsttatii« the steps 

involved with deleting a service PA210. Referring now to Figs. 75 and 76. 

1462.0010000 



2116162 



. 143. 

in a step FD2QZ server modtor FA3i2 nnds a DEUTK SERVICB 
R£QUEST FD1Q2 to oontrol prooen FA202« DELEIE SERVICE 
EKdUEST FDt02 Is a tequest that a piftlcttlar service PA210 be deleted 
from DBS BA1(M, The service FA210 being deteted Is leiiDned to as 
canoelled service PA210C. 

In a step FD204, omtrol process FA202 determines wh^her that 
caaedled service FA210C exists. 

If csnoeUed service FA210C does exist, control process FA2Q2 sends 
a HEUTB MESSAGE FD104 lo delete canoelled service FA210C. Iliis 
occurs In a step FOI06. 

In a step FD20B, cancelled service FA210C sends a SERVICE 
DELETED ME^GE FD106 to oontrol process PA2Q2. SERVICE 
DEIXm) MESSAGE FD106 Infornu control process PA202 diat csnoelled 
service FA21K hss performed all die necessary (unctions In sttp FD208 Id 
shut itsdf down. 

In a step FD210, cancelled service FA210C shuts itielf down. In this 
step, cancetted service FA210C closes any datsbases diat were sssociaied witfi 
it, canodled service PA210C breaks its oonnectkw to die oetwmk (it doses 
ttt network soctet), and canoelled servtee FA210C erases Its portion of duued 
roemivy FA206. Cancelled service FA210C dien returns diis portion of 
shared memory FA206 for odier uses. 

Inasiep FD212, oontrol process FA2Q2 sends a DELETE SERVICE 
RESPONSE FDI08 to server monitor FA212. DELETE SERVICE 
RESFOraE FD108 informs server moniior FA212 diat cancelled service 
PA210C has been deleted. 
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In t Hep FD214, oontio! piocesi PA302 updates ihand memoiy 
PA206 to indkile chat canodled lervkst FA2 IOC wttl no kinier be utiUcii« 
iti portion of ihared tnemcKy PA206. 

The above diacuirioo deacribei bow an individual aenrioe FA210 b 
ihutdom. The process by which the endm DBS BAlOltediutdovm is now 
des crib ed. Pig. 77 is tn opentkmal flow diagiam ilhistiatiqK tlie attps 
involved in shutting down DBS BA104, Referring now id Figs. 15^ 76, and 
77, to shot down DBS BA104, server monifior PA212 sends t DilSre 
SERVER RBQUBSTPD122 to comn)lpfooessFA202. TbisoocufBinasiep 
FD3Q2. Upon itoeipt of DELETE SERVER RBQUEST FD122, cootXDi 
process PA2aZ sends a WLETE SERVICE ME8SACT FD104 to ench 
aervlce FA210 that is operational. 

In a aiEp FD306, exh service FA210 Attti Itself down as described 
above wlds tefiBrenoe to step FD208. 

In a step FD310« each service FA210 sends a SERVICE DELEIID 
MESSAGE PD106, indicatmg to control process FA202 diat service PA210 
Is shut down. 

In a step PD312, control process FA202 sends a SHUT DOWN 
SH^AL PD126 to sttts process FA20B. In a piefened embodiment, stats 
process FA208 tloes not commutdcate via LAN BA122. InsMd, in die 
preferred onbodhnent, stats process FA20B is a Uinx^ process diat 
communicaies via Unix* ^gnals to control process FA202. 

In a s^ FD314, upon recdpt of SBUT DOWN SIOiAL FD126, 
stats process FA208 returns its portion of shared neoory FA206«>the system 
for use by other processes. 
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In a itop PD3I8, oomrol prooesB PA2Q2 Koib a raUR W 
RESPQNS£n)124lDaerveriindlDrPA212. Deteaerver iMponioFD124 
infoma server nionim FA212 that Ibe DBS &A 104 hai been ihut down. 

X4LJ S-fttto Wnf ElaMtm S^rw BAJ04 

Convemiont] database aerven aeareh for lequested data in a highly 
aofbwe^gtenalve wanner. With theMconv cBH o n a l ae r vera , drtriiaae aeaicfaea 
afe coded in aoltwaie. Hmelbn, If a change ta made lo die deaived aaaich, 
die aeaich code haa id mocfifiedv leco mp i te d, and r ateaae d. Tliia la dme 
Gonanndog and afteta aervloe. 

One iedink|iie uaed by DBS BA104 ia a data^ven appnacb to 
aeaiebea. In diia approach, d» aeaich la made baaed oo leooda in die 
databaae. DBS &A104 aearehea dmwgh a aeriea of recoida to find a correct 
leoofd having die dtslred <bta. The aeamh ia perfbnned by unng a key to 
find an initial, or loot, reoofd. Data found in varioitafielda in die root record 
are uaed to find a next record in die aerlea. Similaily, datt found in fielda in 
dila next ncoid ate uaed to find a aubaequent next reooid. Thia aeareh 
oominuea undl a laat record ia fbund. 

An advantage of this data-driven approach b diat aearchea aie leaa 
aoftware-intenaive. The aeareh ia driven by die data oomalned in each record 
found in a aeiiea* Therefore, the aeaich itiategy can be changed aimply by 
updating flelda (data) In aome or all of die recorda. 

Additionally, moat oonventiond databaae aerven require diat 
con n ectiona between diema and aervera be catabHahed before any reqneata can 
be made. Thla meana diat dte dloit and lervermuat firtt oommunicafie wtdi 
each odier to exchange bifonnatioo about each odier. Thia nnut be drae 
before any data ia retrieved. The conventional databaae aerver is tiien 
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re^Kwdbteforimimgii^cacfadlem'auaeQf diediti^^ Air coouDBple, the 
dialMieiervBris reqioiuible for luiowlqg whether te 
what that diem*! current position It in die file. This mamgement overind 
takes away ftom die perftmnance of die daiabaie. 

The DBS BA104 aooonilng id die pmem invendon does not lequite 
a session to be estsMlihed befoie lufiHiuadon can be eichangfld between the 
diem and serw. Widi DBS BAIM. it it die lespomibili^ of eadi diem 
usingDBSBAlOitomaim^ntiadiofltBpoaidonindiefUe. Byddfdqgdus 
responsibiiity to die dient, DBS BA104 can conu enua ie more on die Cade of 
ddiv the actnJ look-ups, and less on inanageinefltOYnheMl. Thus look-ups 
using DBS BA104 an extremdy tet 

Td iOustrate die manaer in wideb DBS BAIM peffbnns seudies for 
data leuuids, a data aeaich is now desnribed In tenns of two examples. The 
first example b a seardiperfbrmedl^ DBS BAI04 when it itodvcs a GET 
CALL m MESSAGB BA306 fhrni CMP BAia2. The second example is 
how DBS BA104 poforms a search when it leodves a request far a called 
number tnmsladon, such as an 800 number tmnsladon. 

2.4LJII CaflIPL— UaUig f^iiaiasf Stnw 

A data aeaich in icsponse to a CAUL n> L0OK4JP MESSAGE 
BA306 is DOW described. Pig.7SAisadiagnuninttsttadngtheo(mfiguiadon 
of a call ID leoocd in CALL ID DATABASE PA214A. ReGsning now to 
Pig. 78A, die search of CALL ID DATABASE FA214A is a aeaich 
perfemied using CAIX ID RBCOKDSFP4Q2. CALLIDRfiOOIIDmaZ 
indndea several ftelds. These fields indude a NUMBER FIELD a 
TYPE FIELD FH34, an IDENTIFIER FIELD FF436, a NEXT 
IDENTIFIER FIELD FF440, DATA FIELD PF442, and a TYP£ USf 
FF444. 
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NUMBER VIELD FP432 can include infonution ndi u ANl, time 
of flay, day of week, called nuniber, originadng number, and the Ito. TVn 
raOi) FP434 can contain infonnatkm such as switch dicoit, calked number, 
types of called nunter, authorisation code, time of <tey, day of wedc, type of 
ANU and tfK like. mE^r^FIER FIELJ> FP436 is used to identify a level 
witUn CAU. n> DATABASE FA2UA at which CAIX m RBC^ 
lerides* 

NE3CT mENlinER nEIi> PH40 indicate 
DATABASE PA214A at which die seaich wtll oondmie. 

DATA FIELD FF442 otmttlns die call parameten. and optionally 
additional infbnnatlon, for diat CALL ID RECORD FF402. 

TYPE LIST FIELD FF444 is used to indicate how to search for die 
next CAUL ID RECORD FP4Q2 widiin CALL ID DATABASE FA214A. 

Searches ttiough CALL ID DATABASE FA2UA are performed 
using a reoonl key FP438. Reoozd key PPi3S comprises NUMBER FIELD 
FF432, TYPE FIELD FP434, and IMMTIFIER FIELD FFi36. 

Fig. 79 is a block diagnm illustrsdng a hlgh4evel concept of how a 
data search in response to a get call ID message BA306 b p er formed. 

ReferriiqE now to Fig. 79, this high-level concept is now described* 
The search fiiat finds a root reoond PF701 and uses root roonl FF70I as a 
present record FF70Z. Presem recocd FF7Q2 is used to cotistnict a templale 
record PP704 having a template key FP706. Template key FF706 and 
template record FF704 are used to search for the next record in the search. 
This record is referred to as "next record FF/OS*. Root record PP701, 
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prtsem record FF702, temptale reoofd FF704, and next leoord FF708 etch 
have die same daia structure as call ID dalabase call ID reooid PP402« 

Fig. 80 is a higb-level opentional ilaw dlagnun illustntiQi the high- 
level conoqH of how a data search in response id a GET CALL ID 
RBQUEST MESSAGE &A306 IS performed. Referring now to Rgi. 79. 80. 
and 78A. in a siq» FF!(tt, call ID aeivice PA210A locatet a root nooid 
FP701 in call ID database PA214A (described in Fig. 83, below). Odl ID 
service FA210A uses root record FF701 as present record FF7Q2. 

In a step PP104. if type list FP444 in preaent reoord FF7Q2 indicaies 
there are no more records to seaidi. the search is done. In this case call 
pammeten &A308 are i^rieved fiom data field FF442 ttf present reooid 
FP7Q2 and sent so CMP BA1Q2. 

If iist FF444 in present nooid FF7Q2 indicaies there are more 
records to search, in a step FF106, present record FF7QZ is used to make a 
template record FF704 for the search. Preseitt record FP7Q2 also defines the 
portion of die database in which to confine die aeaidi. 

In a step FFI08, die temptete record FP704 Is used to search for and 
find die next record FP708. When next lecovd FF708 is found. In a step 
FPUO, next reoord FF708 becomes die new present reoord FF702, and die 
search process oondmies at step FFICM. 

A more detailed description of die process by which call ID tfadafaaae 
FF214A is searched is now be described. Fig. 81 is a hiiMc^ opeia^donal 
flow diagram IUu8»radi« die basic steps pc rfarmed when DBS BA 104 receives 
aGETCAUlDRfiVIESTBA306ftomCMPBAiai. Fig. 82isadetsiled 
oper a t i onal fkyw diagram illustiatmg the mamiBr in which DBS BA104 
searches for die appropriate data reocml in response to aget calllD message 
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P^. 83, described bdow, li a ddalled cpendom] fkvw dingmin 
lllustnting the meimer in wMch DBS BA1(M finds e rooi raooid when 
peifunuiQg the scuch. 

Referring DOW to Pigt. 14and8MnastepFF2a2,CMPBAlQ2widi 
t GET CALUD RBQUB8T BA3Q6 DBS BA104. 

In reapocae to GKT CALL ID REQUEST BAM. DBS BAICM 
nQoeise8ncallIDditnbtiePA214A. Thii access is performed using cell ID 
dstabaae service PA21QA. This aooeis to performed in a step PF204. 

In a step PP20&, DBS BA104 searches far call parametm BA308 
requested by get calllD message BA306. TUs occurs In a step PP206. More 
specifically. In step PP206, call ID dstsbass service PAllOA searches call ID 
database PA214A for the correct call ID record PP402 dttt contains the data 
(call pammeters BA308) requested by get call ID meassge BA30& 

Pig. 82isanopenitionalflowdi«grsmillustnUii«theinannerinwhich 
dils search in step PP206 is p er fo r m ed. Turning now to Pig. 82. in a step 
FP3(S» call ID dandMse service FA210A first locates root record PF701, 
Root lecord PP701 is the record used to begin die search fior call parameters 
BA308. The manner in which DBS BA104 finds root record PP701 is fully 
described widi reference to Pig. 81 below. 

In a step PP303, loot record PPTOl found in step PP3Q2 is designsted 
as present record PF702 for die purpose of performing die search operation. 

lna8tepPP304,preseMreoordPF7Q2 isssved. As will be described 
below, if no subsequent call ID record PP4Q2 is fbund In die search, data 
PF442 within present record PP7QZ are returned as call paiameters BA308. 
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In a tiep FF306» all ID databue tervice FA210A examtneft 9pe litt 
FP444. list FP444 iodudei aeveial leaich QrpM ScaidiQfpei 
PP404 an Hited In 9pa liA FPi44 in the order in which they are to be toed 
for the learch. In other wofdi, they are prioritind. Themich isperfarmed 
S at step Ff^udiig die Ugliest prkxityaeaidi type Ff^i^ 

Id a itep FF308. If te highett priority learch 9pe PP404 of preeem 
reoofd FF702 indicaiei die leardi is oompleted, Qn a pfeferred embodiment, 
is a *0*), present reooid FF702 is die leooid dad contains call p w am e iBta 
BA308 widdn its data field FP442. In diis case, die opeiation condmies at 
10 step FF208 (Fig. SI). 

On die other hatidjf fai step FF30fi it is decennined diat die first type 
FF404 In 9pe list FP4a does not indlcalB diat die seanh done (Is inc a 0 
in a prefemd endxidiroent), die search oondnues in a step FF310* 

In stq> FF310, call ID database service FA210A uses die seaich type 
IS FP404 examined in Step FF308 to set 19 iBinitaBTBCoidFPTM Teraphle 

record is laed to seanA for next call ID record FFWl in die seaiA Indds 
step, database service FA210 builds lemptaiie reooid FFTOi by putting die 
seandi type PP404 into we field FP434 of tmplattreoonlPF704. The type 
imUcated by aeaich type FF404 is put into die mnnber fidd F^^ 
20 record FF704, Tlie next identifier FF440 from present rscoid PF702 b pot 

in die Identifier fleU of tempfade VBoord FF704. 

These dnee fields m template call ID reoonl FP4QZ ooR^nse templaie 
record key FF706. It is dus reooid key FF706 tint is used to search for die 
next call ID record FP4Q2 In dK search. CaU ID database wvioe FA210A 
25 aeardn for next record FF708 by searching flora record MioseieoQvdke^ 

FP438 imtehes die record key FF706 of template record FF704. 
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In a Mep iho midi uting tenplile moid 
Tbit aeaidi is peifiDnned at a level in call ID datatmae PA2 t4A Meotlfied by 
nunklendfier PI^40orpieaBttieooid PPTU This limitt the aeareb ID die 
group of call ID reooidB FfWl exisdng at diat level widiin call ID daiabaie 
PA214A. 

In a itq) PF3I4« if die next leooid FF7(n In die leaidi is found* die 
apeiadmicondnue8at8ttpFF31& If, on die odier hand* ant leooid FP708 
is not found, die cpeiadoo oondnim at a step PF318. 

In a Stop FF316, If next nooid PP7CM is found, noxt leooed FE708 
beoomespiesemieooidFPTaianddieaeaichooRdnuesatilqiil^^ TIds 
new pttsent record FF702 (previously next record FF708) becomes present 
recoid FF7Q2 for the putpose of the aoaich* 

If next record FF708 Is not found, in step PP3t8, call ID look-up 
aefvioe FA214A eumlnes die next hitfiest priority type FP404 in qfpe list 
PP444 of present record FP7Q2 to detemine If any addldonal searches are to 
be performed. The opendion now condnues id step FP308, where it is 
determined whether diis next highest priority search type PP404 indicates die 
search is oonqi>leted. If die search is not con^ileied, die aearcb condnues In 
step PF310 using dtii next highest priority search ty^ PP404 and present 
record FP702 lo set up seareh parameters. 

If dds next I4fl^ priority search type FF404 indicates die search is 
complMd. the openuioo condnues at step FF208 (Pig. 81). 

Reforriqg now to F^. 81, in a step FF208, call ID look-up service 
FA210A sends data PP442 found in die last saved present record PPTOZ to 
CMPBA1Q2. This dstaFF442 is data diat makes iq> call panmetersBA308. 
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The flm ttp In perfonnliii the mreh of call ID dttriNUo PA2i4A 
oocufBinilq»FF3QZ. The piDCCM by which call ID dintwir aeivice PA21(IA 
finda root itooid FP701 U now deacribed. F|t* O u a block dingiuD 
Uliutndng ihepfooeai by which ciU ID daliteae aervice FA21QA fiadi not 
reooidPPTOI. ng.78Biatdfa^giim!lluatnttiii§theBtniduieofa 
uied ID aeaicfa for root record FF701 ftfdilhutiatb^ PPKM, 

Refeniqg now id Pig. 83, in a FR9Q2 call ID datibm aervice 
PA210Aabteliiaaawiieh nuntoandadrouitmmiber infetciUIDfequett 
meaivie BA3Q6. In a attp FFS04, ihia iwlidi nunter and dicutt miinber 
found In get call ID reqiieAmeaiage&A306aieoaedaa a number field PPS32 
ofaaeaicfaki^PP8Q2. 

lnaatcpFRW,dieawttchdicidtidem<flcatiDninchidBdm 
requeat mesaage BA306 b Inaerted in type field PF834 of aeardi key FPBQ2. 

In a atep PFS08. '0' ia uaed aa die idendfier PP836 of aeaich isey 

FF802. 

In a aiep FFSIO, call ID databaae aervice PA2I0A oaea aeaich key 
FP8Q2 ID aeaidi for root record FFTOl. In dtU atep, call ID databaae aervloe 
PA210A is uili« aeifdi key PF8Q2 id find a root record PF701 having a 
number field PF832 and a 9pe fidd PF834 matddqg dioae of aeareh key 
FF802. Idendfier FP836indicalBa dad a aeavdi will be performed on levdQ. 
lna8ttpPFS12,tfiootTeomdFF701 iafiDimd,theQpeutionooadniieaatattp 
FF303 yfhm root record FF701 beoomea a picaent record FP702 and die 
aeaich ia performed as deacribed widi refoffBOoe to F^ 82 and 8L 

If rootrDcoidn^l is not found, in a aiep PRS14, a dehult rooord is 
retrieved containing defoultdaAFP844. Tlu8delhultdalaFP844ls vetumed 
as cdl paruneters BA308. 
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14.3a Nmmktr 7hPUiKi0W Lookrtip VsUit Dmbm Strw 

Anodier eauinpte illumdng nnmaer in which DBS BA104 
perfofiitticaichesitaieaichfDraimin^ The nunner in which 

DBSBA104perf6niiimiiitertnm^ Pig. 84 

UadbgmmtttoitiatfaigatruiiUtore^ 85isanopeiition&l 
flow diagram Uliutnting (he procettof peribnniog a numb^ trunbdon lock- 
up. Hg. 96 tea data ftow diagram illustndngte data fl^ 
a numbw tranitetion ii requcstBd. 

Refeniqg now to Rg. 84, mimber tnmlatioai an pcr for roed uiiog a 
tnnslatai nooid PG102. Tteuladon reooids PQ102 indudea PARENT ID 
nM roiCM, aTYR OPROUUNG field Fai06, aNUMUOl field PQ108, 
aROirniNVOfleklPGUO.andaTESMn^ FQ112. 
PARSNT ID field PQ104, TVn OF ROUTING field FG106, NUMBER 
field rai08, and ROinV INFO nSIJ> PQUO make up a trai^ 
key FQIU. Translation nrch key PGIU is used to aeaich for the ocnrect 
tnntlitkKi itooid PQ102. 

Refbrring now to Figs. 84. 85 and 86, in a step PG202 DBS BA104 
receives a NUMBER TRANSLATION REQUEST F0322 from CMP 
BA102, More specifically, number translation aeivioe FA210B receives 
number translation request PG322. 

In a step FG204, number translation service FA210B locates a route 
record PG402 for die leuch. Root record FG4aZ te found nmply by lookii^ 
at die root level fbr a reoord having a number In the number fiekl PQ 108 drat 
is die number id be tooked up. 

In a step PG206, information in NUMBER IRANSLATICm 
REQUEST FG322 is knded into root record PG4Q2 to continue the seaicfa. 
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In the cue of a foot record P04Q2, the pvttt ID is '0' (inificttii« level (0. 
Route Infbmution coimined in number truHhtioci lequeti BA322 it loeded 
into ROUTE INFORMATION Md FOllO of root leoml PG4a2. For 
exanq)le, if the type .of routing in TVFE OF ROUTING VIEW PQ106 of 
root itoord PG4Q2 Is origlnttlQg stale, then the state in which the call 
originated is losded into ROUTE INFORMAHON field FGUO of root 
record PG4Q2. THus, if die penon pladqg die call origfamied die call in 
Tennessee, "Tennessee* will be the stale loaded into route inftMmatlon field 
FQIIO. In a step PQ208, nuniber tnusladan service FA21QB accesses 
tramlatSon database PA214B to search for a record havii^ fields dot maidi 
root record PGi22. In dds step, number tiaasfaaion service FA210B is 
searchliv for die neat record PG124 in die search. 

If die next record PG124 toftxind (dedto block PQ2]a), die search 
ooiidmies at step PQ206. In this and su b se< p i en t tieralioiiSv the typt of roudqg 
listed In TYPE OF ROUTING fidd PG106 in die fiwnd leooid is used to 
direct the sesrch. In nep PQ206, the route informatioa from nimlm 
trandadim request BA322 U loaded into ROUR INTORMATKIN field 
FOllO. I^exan^le, diU next level of search m^y indicate diat die Qpe of 
routing should be based on dme of di^ dot die cell is ptaoed. Indiiscase.die 
time diat die call was actually ptaced is loaded into ROUTE INFORMATION 
field PGIIO. The process condnues at step FG20B to seaidi for die next 
tecordt having a key dial matches the record that was found in the (mvkws 
iterttlon of PG208 widi die matching route infennation in R0U1E 
INFCMtMAIION fieM PGIIO. 

If no new recoid is found (dedskm bkick PG210) a die next search 
type is normal translation, die search is oomfdelBd. In tha case, number 
translation service FA210B reads termination index PGllZ from die last 
record found (ut, die 'next record" PG124). 
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In » «qi I<ai4, ntimber uantteion aervioe PA^ 
index FG112 to weuA for the tnsdated munbtf in a number tnunbtion 
ditabue FQ3Q2. 

In ft itep PQ216, the tramitied number PQ324 letrteved firm 
tennination databas FG3Q2 ia lem to CMP BA1Q8. 

2.4L4 MnMfrcr IVmatabn 

Many of the mvioei of caU prooeniqg qfstam AB102 ait 
lAiilily to tianstailB a number into anodier number or. altmitively, into a call 
procen defiritkn. The number to be transtauad li geoeralty an 800 nunto, 
but could be anodwr number u well. A tianslation ^atem. uaod to perfonn 
die mmiber tnusdatkmi, ia now deacrflied. Pig. 207 ia a blodc diagram 
iUuatiatIng a rcpreaentative aichitBctuie for a tranalation vyatem. Reforring 
now to Pig. 207, die tnndation ayatem ZAIOO indodea a cianalatM' ZAia2, 
a tnunriator databue ZA104, and a tnrmlnatkin/tnnalalion daiabaae ZA106. 

The main ttandator ZA102 la a aervioe where tianalatioa requeata are 
preoeaaed. TkanalatorZA102GanbeasubayaMiofanoiharNCPABl(Maudi 
aa DBS BAtOi or CMP BA1Q2, or could be a aqniate component Qntemal 
or external to NCP AB104). When tnnalator ZAIOS reoeivea a requeat for 
tnnalation it aenda qoeriea to cianafaaor daiabaae ZA104 and 
tennlnation/tnnslatioadatabaaeZAl06tDrequeatloQk-vpa. TrenatatorZA102 
can alao qoeiy other databaaea, audiaaanNPAdatahaae, tf needed to obtain 
additional information. 

The tnnaiator daiabaae 2LM04 containa Information required to 
perform aeaichea vaaed on a call ANI, time, day. atate. and LATA. In one 
embodimem, tnnaiator databaae ZA104 ia a tree format witfi evh called or 
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dialed (into the iwitchnetviKMk)niiii^ EmA 
tevd of the tree conpriM one teaich Q^pe end in optioml dcfiudt nooid. 

When tnmtlator ZA102 conunenoes a Mich, it is begun in tnntlttor 
databaae ZA104 at the foot ievd. The root leoonl, and each ■ubwquem 
record contains tmtnictioni to allow aeaiching for the next record at the next 
level. The learefa pngmes thiou^ the tree fnxn one reooid to the next* 
usi^g infomation in the moit recently found reooid to seaicfc fior the next 
record. The acarcfa continues through ai many leveii as requirBd until the btt 
record In die aeardi is found. This icooid contains a tmmmtiQB index. 

The cianslation dien continues by seatdiir^ in tennination/tnnslation 
databaae ZA106. The aeaich is based on die called number and die 
termination Index retrieved from translator database ZAlOi. The search 
obtairo die 10-digit termhiadng number or altemstively, calllD infisnnaticm 
used to route die call for additional operator handling. 

The transladon ^siem ZAIOO allows oonptex tnnalatett to be 
performed on any given called nunber, while usmg only a few terminatioo 
records in die termfaiadon/ttandadondattbaseZAlCNL Specifically, only one 
record is required for each 10-digit terminating number and for each console 
roudi^. When a spedfic called nundier is changiBd (fbr exampk widi "800 
On-dieQo*), onlydietenninadon index reooid has lobe changed to le-raute 
die call. 

A valtdadon ^ystm AG1Q2 is provictod to vaHdate certain pieces of 
informatkm before a call is touted to a terminating Gusfeoiner 
aterminatir«user AA106B. For exaiqple, if originating user AAlOfiAplwes 
a callit« card call, valtdatkm system AG1Q2 can be used to determine if die 
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cdiiog cud mtmlier it vilid. In ocher wonts, valUition ByHem AQ102 
vilktot the ctlHng card number. 

Other eunvles of call information that can be validated before a call 
ia touted to a detfination are whedier a ciedit caid number ia valid for credit 
S card calla, whether the ori^nating uaer AAi06A m customer AAllO Is 

audmiiadtDcailacertidngeQgnphicdestinatiQiL These are examples only, 
and should in no way be constnied to Ihnit the uses of validation system 
AO102 to diese cuampics. 

The interfooe between vaiidsdon system AG1€2 and opeiator consoles 
10 ABlOSUnowdescrlbed. Rg. STUaldgh-levelblockdtagiiamiihi^Qgan 

iniertee between cpeiator consoles AB108 and validatioo aystem AGi02. 
Refonrii^ to Hg. 87, when an operator console AB108 hu a piece of 
informadon that must be validated, openfior console AB108 sends a validation 
request GA122 to validation system AG1Q2. Validadon request GA122 
15 includes Informadon dua operator console AB108 needs to have validated. 

Upon receipt of validation request GA122, valldadon system AG1Q2 
evaluates die infmnation to determine whedier it is valid. The maimer in 
which dtts is sooomplished Is folly described in this secdon of die documem. 
Once die valldadon is performed, validation system AG102 sends a validation 
20 response GA124 to dte opefitor console AB108 diat sem valictadon request 

GA122. Validation response GA124 provides informadon to operator oonsc^ 
AB108 regarding whedier die inftmnatimi is valid. 

For example, if a user phnes a call uaingacalllng card, die operator 
console sends a valldadon request GA122 to valldadon system AG102 to 
25 validate die calling card number. Upon receipt of valldadon request QA122, 

validation system checks die calling card number against validadtm datsbases 
(discussed below) to determine whedier die calllt^ card number is valid. 
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Onoe a detenniiiation hu been made at cd whether the cdlim oud numiier 

given ii viIM, thb infonution ii provided lo openlor oonaole ABUM to die 

form of validation mpoim OAI24. If die calllm cud nturiber is valid, 

opeialDr oonaok AB108 aendi opeoior reqmnae daia AB126 10 

widi die iofomadott dm die number it valid and die adi am be oomplettd. 

NCP AB104 dien ccmunands matrii nriidi AB106 to route die call lo die 

deidnadon. 

Hg. 88 is a block di«giam ilhistndAg validadoo qfstem AG1Q2 in 
gnmer detail. Validadon system AO102inchides a validator GA202 and an 
external validation gateway GA204. Validadoa lystem AGIOZ also indodes 
seven! databases, or mUes, wherein cettato validatioD infonnadon can be 
found. These include a p-code database GA222, a hol/oolddatdbOBeQA224, 
a validation Indea databaae aA226, and a validadon Woek daidbeaeGA228. 

Ilie openuion of valldatfon system AQ1Q2 is now described. Rg. 89 
is a high-level operadonal flow dii^nm illustndqgdieopentiaoof vatidation 
system AG102. Referrii^ to Figs. 88 and 89, in a step GA302, validator 
GA202 receives validation request QA122. Upon receipt (tfvaUdaikin request 
QA122, vaUdaSBT GA20Z aocesaes pKXide dssabase QA222 to retrieve p-^ 
GA232 for die particular validadon operadoo. F€odeGA232 comprises a set 
of instnicdons to tell valldttor OA2()2 how to pnform die vaUdadOQ necessary 
for die paidcular validation request GA122. ITib use ofp<€odeGA232 allows 
die validation poformed by vaUdatKn- QA2Q2 lo be cusfendnd for each 
customer AAUO or user AA106. Thus, different levels and types of 
vaUdation can be perfoiined based on the Qfpe of call placsed, the cu M u ra ei 
AAl to dirougb which die call was placed Ctf any), die particular user AA106« 
or odier unique charKterisdcs. 

If diere is no p-code Am- a particular vaKdatico re^Mt GAI22. in a 
step GA304, validation systm sends validation response GA124 to opendor 
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oonsc^ AB108 infbrndiig operator oontole AB108 thai the cill caimot be 
valictod. 

If |H»de QA232 Is Ibund fbr die validation request OA122, p-code 
OA232 is leirieved by validator GA2Q2. Hie letrteved |H»de GA232 is 
5 exeoued by valklalorQAIOZ to perform die valldatton. Thltaocuninastep 

QA306. T6exeaitBihoodeOA232, validator OA2Q2Mk]m die lii^^ 
fouiul In p-oode GA232. Tbeae instnicdons direct valk^ 
spedficvaUdadoncperatkiiis. Step OA306ts now described in greater detail. 
91 Is an operatbaal flow diagram Ulustradog die steps involved in 
to execndng the p"Oode. 

Once tlie p-oode Is executed by validator QA202, validator OA202 
sends valldatloo response OA124 to cperaior oomole AB108. This occurs in 
astepQAm 

Pig. 90, which comprises Pigs. 91 and 92, Is an operational flow chart 
15 illustrsdng an example of how validator QA202 executes |hCode OA232 in 

stepGA306. Merring now to Figs. 88 and 91, some valktadons may require 
dnt a hot/cold file GA234 and hot/cdd database GA224 be checked to 
determine if Ac call can be validated. In dilscase, validator QA202 retrieves 
hot/coU file GA234 fat dot particular call firom hol/coki database GA224. 
20 This occurs In a step GA402. Hot/odd file GA234 m^y be indexed by callii^ 

card mmter, fbr exan^le, to determine wbedier diat calling card number is 
valid. Hot/ooU file GA234 oouU also be indexed on credit card mimbers, 
customer Idemiffcadon, user idendfication, and die like. 

In a step GA404, validator OA2Q2 diedca hot/cold file GA234 to 
25 determine whetherdieparameter to be validated is hot or cold. For example, 

validator OA202 determines whedier die calling card number fbr a calling card 
call ishotoroold. 
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[f the mtmbcr it hot, valiibtioa mpome OA124 ii lett id opemor 
console ABlCMindkadn^lhat the cdl CUM be plaoed« TUsoocuninaitep 
OA406. An eumple of when diii might occur it when a cilliqg caid is 
reported txakn and the number entered in hot/oold file QA234 u hat» «4ieo 
a calliiv cud ii canodled by a uier AA106 or a cuikmier AA! 10, or for any 
other reaion dnt card ihouU automitkally be conwd et ed invalid. 

Ai a second example, an origimtlqg telqihone number roiy be lined 
at "hot" if for lome icuon calls are to be btodtBd fitom diat number. One 
reason for Usdng an origioadng number as "bat* it where dttt mnnber is used 
fkequemlytopeipeiraiefnuid. PorexBmple.apinicidvoi|ghHdi«ideplione 
number may hsve been used in die past lo plsoe ioqgHHsianoe alb umig 
stolen dlliog cud numben. In dils case, this oit|}nBtiqg telephone mmter 
will be Wockad firom placing calling card calb. 

If in step GA404 validator OA2Q2 detennines dmt die paiameier 
checked is cold, validator OA2Q2 sends a validadcm response GA124 
indicadng dnt die call is validued end should be rauied to die destination. 
This occun in a step 0A4<^ 

Use of hot/cold file GA234 U not limited to validatiQg calling card 
nundm bm can be used 10 validtfe mmmos other call paiamem 
sidncriber AAl 14 identification, use of a liMtnre Iqr a usv 
like. 

If in step GA404 die paxameter diedied is not hot or cold, vaKdaior 
GA2a2 accesses validation index database GA226 to letiieve a valkhtion 
index. This occurs in a step GASIO. if validation index GA226 is found for 
die pardcutoradi (dedsionbk)CkGAS12), validatioa index GA226 is ci^^ 
in a step GAS14 to determine if tint call is blocked. Validation qrstem 
AG1Q2 is in^mmtted to allow Gelephone calls ft> be btocked far numerous 
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ituou. For eaiample, a particular uaerM106 may be 
ocTtdo dttes. certain area codes, or at certain timei of day. Additionally, 
certain men may be limiied to calling only cattln telephone numben or 
cenaio dties and may be limited tt> udng kmg distance aervicei at certain 
times of day. Tbeae llmitatkma, ex blocks, can be plioed on ImBvidual users, 
ipedfic caUlQg card numbera or debit cards, or on q>edfic customers AA 110 
oriubscribersAAlU. This provides altnastunlifnited flexibility to custonilae 
die ^sttm In setdog up die loog distsnoe cspabilities provided to partioilar 
diinMer carfim or users. To check ifa number is blocked in step GAS14, 
a sertes of aeaidies Is done in die vaftlock dirtsbase (OA280 to see if die cal^ 
teuld be blocked. These searches aie done until a record Is found to be 
btocked or no ftuther records are found. Bach record found contains data on 
how CD search for next record. All of these records form a tree which is 
traversed during these searches. 

If die nuniber is blocked (dedskm bkick QAS16), validator GA2Q2 
sends valklatkm response OA!24, Indicstiag that the call cannot be routed. 
This oocun in a step QA518. If, on die odier hand, die number is not 
bkickBd(dedsion block OAS 16), valuator QA2C)2 proceeds to check internal 
valkladon wfaete required. Additionally, if dm b no valklatkm index 
QA236, valklator OA202 performs sn external validatkm if required. The 
external valkbdon is performed in a step GAS18. External valktatfons can 
mehide valkladi« a credit card number, addrd par^ collect call, a debit card 
nunter, a calUtig card nurober, and nuinerous other parameters diat ini^ 
have to be vaUdaied in an external source. 

In step GA5 18, valktolor OA202 sends a request to external valklation 
gateway GA204 requesting tint die parameter be valklatBd. For exami^, 
valUattv GA202 may send a ttqoest to external valklation gateway GA204 to 
obtaJn an external validation an a credit card number. In tiiis exanqile, 
external valklation gateway dien sends a request to an external source to 
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valklaie the credit card number. Om example of such an eMfnal loiuce U 
theaenffcseooiiqttny luiinrauGBnl^d(locatBdlDR Lauderdale, Florida, 
which normally valMalBicredil card munbert. Whenthepoittiveor 
negative reqxnne ii received from CMd^Tcl, external validatkm gateway 
5 GA204 proWdes diis mibnnatioo 10 validaior GA2(B. If extenaJ validation 

indkaies that die call is blocked in a aiep QAS20« a validatioo teqxmse 
GA124 is sent to cpeiaiKv console AB108 hi a snp GA5i8 ladicatiiv diat the 
call ihould not be routed. IflnstepGASTOitlsdetennlnedlliatdiecaUisnot 
blocked, valldatkin response GA124 is sem to cpemtor console ABIOS 
10 indicating tfiat the call can be rauted. 

It abouM be noted dist external validadon does not need to be 
perfbnned on eveiy C8il« i.e. thne (br which the card number reooid is 
reskient widiin die DBS BAI04. When external validation is not neoesaiy. 
Stops QAS18 and OA520 can be akipped. Additkm^, the oOer checks such 

15 u die check of hoc/ookldaiabaaeGA224 and validadoa index GA226 can ato 

be bypassed if diese checks are not retpdred for die particular call. The p- 
oode datsftase OA222 is what is used to provide din flexibiliv for diflerem 
types of calls, different subscribeis AA114. and difforem users AA106. 
Different insoucdons can be set up hi p-code database QA222 to command 

20 valuator QA20a to vaHdaie calls in diffeient ways. For eumfrte, fliere nu^ 

be a different p-code for calling cards atsl for diMt cards and <fifferent 
customers and users may each hive different vsHdatkm procedures depe ndin g 
on die type ofservioe they request fmn call procesuQg system AB102. Thus, 
die use of different p^oode fife GA232 for each Qfpe of valkfaokm operstion 

25 allows validations to be customised to a particular user AA10$« or customer 

AAllO. It should also be noted diatadAdonal databases could be provided 
toperfcmnaddltiontf validadoos. Forexampfe,add)iiGarddttabaaeGA230 
oouki be provkled to determine whedier a particuhu* deWt card nwnber is v^ 
and whether diere are sufRctent fiinds in tfnt card to pomit die call to be 
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nwttd. Ddbit canbocwM 1180 be handed extenidly, via u 
gatewi^ G A204. 

The Qrpes of validation deicribed widi lefbrenoe co validation system 
AGIO! are ihown by wi^ of enunirie lo illintfaie d» manner in which 
validator GA2Q2 perfonna a vaUdatkm. Theae examples should not be 
oonstnied to lindt the use of villdatkm ^yaim AGIQ2 to only dm 

In oHiventiottal syatema, valldadon » typically performed by operator 
conaolea ABlOft. In ttmm cases, die conaoles AB108 did die kiok-iq>s to 
determine whedier the call was valid and should be routed. Any changa diat 
had to be inade to die validation process in these OGOvendonal system required 
dnt chames had to be made to eadi opmior oonaole ABIOB. A benefit 
provided by call piooessiiv qfstem AB102 la diatall of die validation fimedtm 
is moved to a singkcentialind location and valldatloaqfsmAGl^^ Asa 
result, chai^ tfi die validatkm process need only be implemented ID a ^ngle 
system instead of to each individual opecstor console AB108* Addidonally, 
die use of p-code allows for customlation and allows chames to be made 
quickly and efBdendy by idmply dian|li« die tnstrucdons found in p-oode 
database GA222. 

A key feature provided by diis arddtecture Is diat chaq^ to die 
validation process can be made cpiickly and easily by simply updating p<ode 
database QA222. VaUdalor GA202 doa not have lo be recompiled to 
implement changes to die valldadon process. The manner In whkdi p-cbde 
database is updated is diacusied hi detail behiw widi reference to Fig. 93. 

An nddidonal feature provided by diis arddtecture Is dnt it allows 
customiaadon. For example, customer A may wish to allow calls to Osnada 
whereas customer B does not, or customer C may not wish to accept credit 
card calls. Thus, using p<ode, diitd-der carrier customen can request 
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particular custtimiiad aervioes horn call prooeasnit aystem AfilQ2, and 
cuatDmitatkmcanbedooeonaper-cttitoinerbiria. OmnfeaiDthe vaUdatkm 
acheme for each customer can be made by simple changing the p-code 
leoonis. 

Validatiim la not limited lo validation of te cdling mediod auch as 
credit cant or calling caid numb^, but alao alkiwa validation of origiaitmg 
and deatinatioo iBtefdione numbeia. 

In die past, to update validation nietfaoda, opentur consolea ABIM had 
to be removed from operationa and reoompDed with the new valldafinn 
pTooesaea. With numerous opemtor conaoles AB1Q6, such an opontian can 
take n long time and have «n ImpKt m aervioea provided to cuatomen. 
Aooocding to die cunem invention, changea in die wqy a call la validalBd can 
bemade(evenonaperaubacriber AAlUbasia) simply by changing die dan 
in p-code databaae GA222. 

Aa described in this document, call |»Qoeasing qrstem AB1Q2 is a 
highly data-driven system in one embodimem. Becauae of diia, die manner hi 
which data is handled and nudntaioDd is of panmoum importance. Updates 
to databaaesnum be made efficiently and in a dmdy&ahion. Additionally. 
It is critical dat die imegri^ of dam widun diese datahaaea Is maintained at a 
higlh level. 

One way to pnmde for a tolt-toleram opention is to use mlmxed 
*fB!ibirf, This provides system redundancy that allowa a aystmn to coating 
to openie even if one of die redundam databaaes goes down. 
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Om probfem anodsted with itduodamdatibam li chat Uctnbeoomu 
tootiine--consiiininKtoupdilerilda^^ Thiicui 
especially be a problem wheie a relational database is md becaiue of Che 
relativdy slow access dnes associated with relation Hoanver, 
it is impoctaitt that all datshain, boib primaiy and itdimdaiit datahasna, are 
updated at or about the sane time so that die data is curttnt duoughout the 
lysteoL 

To addnas dds prdblem, the inventors have developed a distribiithm 
system intended to ensure that data imecri^ b maimaliwl thioughout the 
system. Aoooiding to die tnventon* oonoc|it, a piimaiy database Is updated 
with an data changes required. These can indude updates, inserts, and 
deledjns. A distribution system reads dieae updates and uses tfiein to update 
all affected slave databaaes. In this manneTt the distribution system ensures 
that all changes made to die primary dandnse are inoocpor^ into die 
affected sfaive databases. 

The disirilmtion system acoordii^ to die preaem invention is now 
des cfib ed widiin the call processing system enviromnent. It should be noted 
dat die distribution system oould be used to effectuate updates to any system 
using redundam databases and is nrt limited to call processing applications or 
the embodiment described herein. 

Fig. 93 is a high-levd block dingram illuttnting die distribution system 
in one enAwdiment Fig. 94 is a high-level apmdmd flow dingmm 
lllustiatiQg die manner in which die distribudon system updates sl^ 
to reflect updates to a primary dttabase. Referring now to Figs. 93 and 94» 
in diis embodiment, distribution system HAIOO inchides a distributor HA102 
and master databases HA106. Master databases HA106ineiudea all cbtabasea 
used by call processing system AB1Q2. Changes are made to master database 
HA106 by order entry HAI04 or updates fhim odier applications HAI08. 
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DlMribiittff HA102 lakes ttmm (Amttgn and qpdaiei tbe ilave daiabam 

HAUO. 

In this embodiment, tteve datthiiM HAllO oompriie die call 
piooesiiqg ilatahaifn uaed lo fttm data lelated id call pwceaatng. Maner 
databases HA 106 Include additional I n lbr matioa that Is not oeceasadly inlsiBd 
10 tall prooessiqg. For example, wma dalriiases HA106 include bilUog 
interoation which is not included in slave databases HAllO in this 
BmbiHliiBentt 

In a step HA2(I2, a date chaofe In call fnooes^ ^slem ABIOZ 
results in a chaqge to data in master dsobaae HA106. Thb data chants can 
be a result of any of sevemi actions. Forexarople, whenacsil isvsceivedby 
call processing system AB1Q2, a BIR BB322 Olhistnled In Ftg. SI) is bidtt te 
die call. BIR BE322 Is used by call |m»es^ qfstem AB1Q2 to nninlBin 
certain billing ittformatiosi. When BIR EB322 Is created or updandtChanfes 
are made to ai^ of aev«nl danbaaes within call processing qfstem AB1Q2. 
These datsbaaes can be coosideted part of master database HA<06 for tbe 
puipose of the discussion of distribudon system HAIOO. 

Once changes are made to nuMr database HA106, it is tmpona^ 
diese dungss also be made to te sbve databases HAllO widdn call 
processhig databaae HAUO, Therefoie, te chaBtss made widiin maser 
database HA106 ait provided to disttibutor HAIQZ. IMstribotor HAIQ2 
detennines wUch of te slave daitfiases H A 1 10 are to leodve aimihff change 
This oocun in a step HA210. 

In a step HA214, distribudon system HAIQZ modifies duae databases 
widiin call piooesrii^datsbase HAllO. Once dus is done, slave daisbases 
contain infonnation that mirrors infonnation in master datalwse HA106. 
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Flg. 94deKribei ttecperttionof dii^^ 
tevd. EMh of the Bttpt within F{g. Man diKUsnd in mon 
with refectnce «i FIgt. 93, 94, 97, 99, 100, and 98. Fif. 95 U a Uodi 
diagmm iUuMii« a lepmemative aichiiBcniie of distribmor HAiQ2 and 

5 roatterdatabuBHA106inonaembo(HmeiiL Referring now to Pig. 95, maanor 

ditabue HA106 compriaet, amoog odwr ddbtea and filet, an BSC table 
HB1Q2, a trigger HBi06, and a delta (A) table HBltO. For eneh tdbk in 
matter databaae HA106, there are diree triggen Qniert, delete, and update) 
HB106 and one delta table HBllO. ThedittibutioDsyiMitideieribed widi 

10 reference to diaqget to an BSC taUe HB1Q2. Thii deao^don afiplles to 

cfaangei to all tiMes In master databaae HAI06 diat are mlnmd in alave 
dantaaeaHAUa 

Dimibutor HA102 oompriaei a dittribudtm aerw HB118, a dealer 
HBI34, a oonngiindoo tdble HBIU, and dlitribi^ tibiei HBm. 
15 Dlitribudon taUea HB122 oonpriie an audit taUe HB126 and a net meange 

table HB130. Queues HB138 can ferdier be pioWded to ctiatribinioo ae^ 
HB1I8 and dealer HBt34 to fedUtate handling of nmage tnffic. Queues 
HB138 can be used (o queue messages to diose ccnnponenta. 

An example of a dijoribudon server HB1I8 is die commercially 
20 avaifadile Open Server, available from Sybase, Inc., 6475 Chrisde Avenue, 

Emeryville, CA 94606. 

Fig.96isanopenttiona] flow diagram inustradng die manner In which 
changes are made to master datidiaseHA106. Fig. 96 flttther describes what 
occurs during step HA202 of Fig. 94. Referring now lo Pigs. 95 and 96, in 
25 a step HB204, data changes for master datsbase HAI06 are wtitten to ESC 

tableHBI02. These are die wnal changes made to databases and fifes widdn 
roaster database HA 106. These changes can Include inserts, deletions, and 
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iqNbtBi Co oxitti^g diM. Hicie chtoges ue icfeiitd to is "evenis* for 

brevity. 

The cfiaivei to muter ditibtio HA106 aie made bjf otder emiy 
HA104 or updilei Ihm odier ippUcitloDi HAlOa. One example of eider 
entry HAICH is die commercially^vailabie Ptwerbuikler tool, availahle fiom 
Poweraoft Corp., 70 Mandaid Road, Buriimiom MA 01809. 

In e itep HB20B, trigser HB106 cultures eveirta (Gi;ai«B8 rnade to 
tabkHB102widiinmaslerdaiabeieHAtOO. lnanpHKll2,trigSBrHB106 
oapieidKae even ftom BSC taUeHBlQl into delta (A) e^ Ttai, 
delta M» HBllO is a taUe comalflii« only die dHU«ei flsade to BSC table 
HB1Q2 needed to iqNiate slave ditaliaietHAl 10. Delta irirteHBl 10 oonlainB 
die inseia, updates, and deletions diat were made to BSC table HB102. 

In a step I1B214. trigger HB106 mads a tr^ nmrngR HB172 to 
dittribution server HB118 in distributor HAIQL Tr^ner messi«e HB172 
informs dlstrlbudon server HBllB dutt event! HBlfi2 are copied into delta 
tableHBllO. lliisinfonns dlstrlbudon mrverHBllSdnttdiere are cbaiiges 
diet need to be made to slave datsbnes widdn call processliig datrinse 
HAllO. As a resuh of die operations dmciibedi^direfiMein to Fig. 96 
(step HA2Q2 of Rg. 94K miter dattee HA106 is updated to reflect all 
cbai^ by order entry HA104 and odier applications HAIOB, ard 
HAlOl IS informed dm diere are cbuiges to be made to ikve databases 
HAllO. TbeopentionnowooMsnueiattteplfA206of Hg. 94. 

Step HA206 of Fig. 94 IS now fiiidier described iiddi refers 
97 and 95. Fig. 97 is an operadonal (low diagmm illuatiadng die numner in 
whicb distributor HA102 receives events HE16Z finm imam diabase HA106 
ami updates lUstribiidcm tables HB122. Referring now to Fig. 97, in a step 
HB304, distribudon server HB118 icodves trigger mestoge HB172 from 
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trigger HBICM. Tlite imUcaies Aat chii^i to » tiAite 

HA106 m mMk and evena HB1€2 ftpftaendng thoK changes are itoitd in 

MtatMHBllO. 

In a flep HB308, diitfibution lerver HB118 lOKb events HB162 ftom 
delta ttbte HBllO. In a step HB312, dstribution aerver HBU8 updsies 
dlttrilmtkm fiibks HB122 bised on te inte^^ 
Step HB312U described In gmoer detail bekywwidir^^ 9». 

In a sttp HB316, dittilmtkm sen«r HBUS sends an cvem Indicate 
mesn«eHB182 to dealer HB134, Event indicatkm niesBi«B HB182 lodicates 
to dealer HB134 diatcweala HB16Z were leoeSved leflectiiQ cli^^ 
in muter database HA106, and diese changes can nofw be raade lo steve 
datriHttBs HAllO* Dlsnibulion server HBU8 then oontiiiues to wait for 
adainond trigger messages HB172 as illustrated by Mtmk loop HB362. 

The manner in which distribution server HBllS updates distribution 
oMes HB122 (step HB312) Is now ftmher described. Pig. 98 Is a diagiam 
lllustratiog a tepres en tative oonfiguiation for audit nMe HB126 in one 
entedimrat Pig. 99 b an qieiatlonal flow dbtgiam iltustrstiog die manner 
In whidi distributicm server HBUS updates distrfbution cables HB122 in one 
CDdKidiBiBia. ReMi« now to Pigs. 95. 98. and 99, distribution tables 
HB122oomprlae an audit table 126 and net message table HB130. AudlttaUe 
HB126 compriaes a plursli^ of fields used id indicate which of die slave 
databases HAl 10 are to be modified, and widi vi^ informaticm. 

In one embodiment, audit tdile HB126 Is made op of severs! raws, 
vtoeln cMh raw Indteates die change to be made and where 0n what 
database) those changes are to be made. In this embodiment, each row of 
audit table HB126 can Include a aervioe number HCIM, a server name 
HC108, a pointer HCI12. an action KC116, and an update flag HC120. 
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Seivioe number HC104 and lerver name HClOB are uaed lo identify die 
databeae lo be modified. Mnter HC112 pointa to a net meaa^ tiB126 
wilbin net meange table HB130 that indlcatea Ifae modifatkma to maater 
databaae HA106. Actkm field HCU6indicatea the actiootalm (for eiample^ 
an inaert, a delete, or an update), and update flag HCilO la uaed to indicate 
when an update aooording to that row has been made. 

Refeniiv now to Figa. !I5, 99, and 98, in a itep HB404, dittribatk» 
aerver HBl 18 ooDverta evem HB163 to die proper fbnnat ID be ined to i^idtt 
atowdttfaaaeaHAllO. Tbla step, if uaed, can oonven events Hfil«2 which 
reflect chaoses to master database HA106 to events that will reflect similar 
chava to slave datsbaaeHAHO. Thus, if master dBtabaseHA106 is of ooe 
^ (for example, a relational datibase) and atave database HAIIO is of 
anodier type (for eaanqile, at tree a suitable conversion can be made. 

In a step H&412, tfistributian aeiw HBl 18 diedcs oimQginatiott table 
HBl 14 to detennlne whedier the sUve daisbaaes dnt are 10 be inodified baaed 
on events HB172 (usii« net messagie HB176) exist within call proceasiQg 
system AB1Q2. Configitntion table HBl 14 cnaiidaina an active Hsc of slave 
databaaes HBl 10 existing widiin call j^ooessing system AB1Q2. Thus, if a 
datsbaae Is not Hated in configuiation table HB114, it does not exist, and 
theiefore camiot be lyrtated* 

In a step HB414. if the sfaive databases that are to be modified baaed 
on events HB172 exist within call prooesni^ system AB102 (u determined in 
step HB412), lUstribatkn aervcr HB118 inserts m message HB176 into net 
messi^ table HB130. Thus, net meaa^ge dUe HB130 oonttuns net message 
HB176 indlcatii« the cfaaives to be made to one or more slave datdnses 
HAIIO. 
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In a MP HB416, dittributicm Mrm HBl 18 updton ludit table HB126 
(oreadideadnitlonMdeCBimiiKdlqfimH^ In 
the entedlmem deicribed above, in cMi 1^ 

a new raw In audit table HB126 for each deadnation. Bach row In die audit 
taUe lodudes pdnter HCU2 which pdms to die oet meaaaie HBl^^ 
nane of die sUve ctatabaae HAUO diat Is to be modified uaing 
HB176. 

Ina aiep HB420 when nodeatinadonsexlat, diatribution aeiver HB118 
canaea event HB!62tt> be deleted from delta laUe HBl 10. Thiaiabecauaeno 
chaogea to slave databases HAllO are iet|uiied. On die odier hand, when 
desdnttkma do exiat, die net meaaage table it qtdaMl in a^ 
audU table la itpdaied in step HB416, diatributkm aerver HBUd cauaea event 
HB16 to be deleted from delta tabk HBllO. In dda caae. tt ia now if) to 
diatributor HA1Q2 to ensure dot the pmper dnnges are made to slave 
daiitaeHAUO. 

The manner in which diatributor HA1Q2 modiflea alave databaaea 
HAllO (ateps HAllO and HA214) to now described, ng. 100 is an 
openttional Bow diagram illustradi^ die mamier in whidi slave databaaea 
HAllO are iqxiated. 

Referring now to Figa. 95 and 100. in t nop HB304. dealer HB134, 
after receiving evem indicadon message HB182, reads die oldeat row 
contained in audit odile HB126. Dealer HB134 to lookii« for specific 
desdnadon alave databaaea HAllO. 

In a step HBS12, dealer HB134 roads die net message HB176 poimed 
to by pointer HC112 of die row retrieved from audit table HB126. Thus, 
dealer HB134 knows which net message HB176 to send to die deadnadon 
slave database HAllO. 
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In a itep HBS16, dealer HB134 modifiet ifaive datidiues HAl 10 wAng 
iietine8i«geHB176udetennioedln8tepHBS12. OnoetfieiDodifiaaioiisifB 
made to die ilave dttabeie HAUO u indictted by die row of mdh tiUe 
HB126, the update fiMg HC120 in diat row is aet to indicate dnutboae chaoiea 
S have been made. 

If more rows exist wMiln audit table HB126 widKNtt update Oifs 
HC120 set, dealer HB134 condmiei at step HBS04 lOMiliv die oMest row 
las not yet been used to modify slave database HAl 10 0.e.. its update flag 
HC120 Is DOC set). If no m«e raws ealat, in a step HBS2S, dealer HB134 
10 waits f6r the next event iwHcaHop mma^s HB138 to be received. 

One advamage of distributim system HAl 10 is ditt trigteis HB106are 
used 10 sin^iQf the operations pertemed and to ensure cbe iutcgiiiy of slave 
danJiases HAl 10 throughout the emUe call processing system. Aadiscussed 
above, a trigger HB106 is called each time a change Is made to a table (for 

IS exanqde. ESC tsbk HB1Q2) widdn master dattee HA106. When this 

happens, distribution system HAIOO captures the changes and distributes them 
to ail die reared slave (destination) databases HAl 10. Diairflwtion system 
HAIOO is tnnsparem to die application making changes to master dautese 
HA106. The spplicatkmmaidng the changBS to master database HA106 is not 

20 Involved widi die process of modi^ng the dave databases HAIIO widi the 

same changes. 

Amidier advantage provided by diatribation lystem HAIOO is diat a 
deha table HBllO is used. Gonvendonal systems uae remote piocedure calls 
to send update data to slave databases HAllO. This procedure is time- 
25 coMumlng. Conventional medwds would mark each affitcted row in a table 

as changed, and then periodteally quay die table to determine which raws 
havechanged. Thus all rows in die changed table had to be examined to find 
changes. Through ^ use of delta table HBl 10, only die dan diat is needed 
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tD^Kte«hve4atrt«9esllAn0U|TOy^ BachMtti 
ttMe HBI IO apnim chu^oi itat m undo to to aswdaied adUe (for 
enmiile. BSC nbte HBIOS). Tbe ditti^ 

HBltQtobeipplMtoteappcq|»fi«tfiita^ TUtroelliod 
5 alkm die i|iplication pafbnniiig the change to mutor cfaurimae HA106 to 

oonlUiw perfomdog tny other »^ 
wakn te chaqiDS to the a ppro pria te ilave databam HAUO. 

Still anodier advantage of diatributkm ^yitem 
leqdie that npdalet to all dtfdnaes be Jmultanenua, This foatttie allowa 
10 dave dMrtift»a HAllO 10 be i^dalBd at tfieir om pace. If any one <rf the 

affccted dave dttahaaes HAUO Is down, die efaaogas are queued until that 
datahaisHAl 10 It ready to receive diem. McanwUle, die odier affected slave 
databases HAllO can be upted. 

5.9 MmHlm JteM^ffpifiMia* 

IS Most leal-cime ptooessing systems rely oo havii^ didr conpooenta 

cpeiadonal at all droes. System downdme may result in a dininudon of 
services provided to customers or a reduction in die amount of product 
manuhctured over a given dme period. QUI processing system AB102 Is no 
difffacnt When components of call processing system are noiHipentioiia] for 

20 whamver reason, die capad^ of die system la diminished. If enough ^ystmna 

are down, diismayiopactdielBvelofsavioeproiMedtosubscribenAAIH. 

CMunple. considBr 1^ vrauld happen if opeiator conaoles 
be dissliled and reconfigured each dme a chai^ is made in die my a call is 
processed. For each console taken down, die lysMm would have diat much 

2S less capadqr to handle opersioraasisted calls. Addidcmally, fbr a system 

having numerous opentor consoles AB108, such a change could take an 
undesinUe leogdi of dme to implemem. 
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One lotution Imptementtd by die invenm Iw 
thuaiehiililydita^ven. Thus^chaqguin diewiyacill bpraoeiied can 
be implementBd by ehanging data oomained in dMa fUn. At a mult, 
aperadooa) code does not have to be itoompiled to implemrat dnotea. For 
example, InAe vaUdadoDayttemtfaettepspefftonnedin valldadi^acaQm 
localed in a dita file In p-code datahaae QA222. Thiu, opentor cooaole 
nnqriy notiflei validator 0X202 what qrpe of validitk» lo perfbm. 
Validation vystem AOI02 perfbrms die valldatkm baaed on ioMrucd^ 
type of validadon found in p<odedaiabaieOA222. Ifadtametodiepraoeai 
followed when performing that (or any) qfpe of validalloD ia teqniied, the 
change can be implemented simply by loading new data in p-code datrimae 
OA222. 

Convendoin] Qfftemt leQid ted opetaliv oottiolet AA106 lo perform the 
validation foncdona. The validttkm fonctkm were not centrally kneed. If 
a change to the way in whidi a call is validated wu reared, diat change had 
to be ImplementBd in each opera tor co n sole. This oaually meant feoompiling 
code In opemtor consoles AB108; a cosdy and time coosumh^ task. 

According to die piesem invention, simple changes to die data (p^ode 
QA232) in p-code datsbase G A222 can be made to implemat die dianges. 
Changes to datshase GA222 can be inqilemeniBd in a onmher of diffieient 
ways. In oi« MiOiodiinM, disuibmkm ^ysm HAIOO, as described abov^ 
Is used to implement changes to databaae QA222. tn an ahenntive 
embodiment, dianges can be inade dhecdy to p-code datsbase GA222 whiiout 
distributfcMi system HAIOO. 

The manner in widch valklttum mediods in p-code database OA222 are 
implemented and updated is now described. Hg. 101 is a block diagram 
illustndng a icpreseniadve architectare uaed to lydatB p-«ode datsbase 
GA222. Fig. 102 is an opetatkmalfkyw chart illustiating die manner in whkh 
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|hOodedaiilimQA222Uupdi(BcL RefMi^ now to Rp. 101 md 102. fend 
ediior/ooinpibrJAlOl touted to craUBvalkhtkmn^ Hme 
methods can be stand cm datalMie 

omo |HX)de dittbtK GA222 to they can be aooested by vtlUaior QA202. If 
desiied, a call-pnoeis database server J A 106 can be used u a server to aooea 
l^code daiiliaae QA222* 

The method in whidi |hOode vaUdstkm mediods ate developed atd 
updated are now described. In te step JA2Q2, an operator creates a 
validation meiliod using editoi/cinnpUer JAIOI. The cpentor develops 
instructkms In editot/oon|riler JAI02 dMUlQg bow a paiticutar valldatioii Is 
tobeperfbnnedbyavalldalorGAlOl. An example of editoiycQnipilerJAlG2 
Is Che oommeidally avaltable Foweibuiider Padcage availaMe fhmi Foweraoft 
Corp., 70 Blancfasid Rood* Buitti«ton, MA 018Q3. EdUw/oonpiler M102 
allows an operator to create methods using simple English language 

In a step JA204, the medwd created using editor/oompiler JA102 is 
ooniplled Into p^oode by editor/oompiler iAlQ2. In a step JA206 
edhor/oompiler JA1Q2 Is used to debug decompiled p-«ode. 

In a step JAM, once die p-code medwd is debugged, it can be loaded 
Into p-code dsiabase GA222. Om in p-code database OA222 it can be 
accessed by validator OA202 as discussed above in the Validation Section of 
thisdooumeoi. 

If desired, the metfiod developed can be stored in datsbase M104 for 
redundancy, and/or later access. Datitese JA104 could be an Independent 
database or file, or could be a database widdn master datrimse HA106. 
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It thodd be noted tet validation methodi aie not lintited lo being 
implememed udng pK»de and numeiau other oonrntkmsoK^ 
In this lii^t, editor/cmnpUer JAIOZ it not limbed id oonpiUng the mednd itto 
p^oode, but could be uaed intlend to coni^ die method into the type (vf 
Instructkm tomat expected 1^ validator QA202. 

Aa Doled above, in one esnibodunent, tlie new p-^ode methodt cftued 
and/or tqidaiBd by editor/oompUer JA 102 can be loaiM into p-code databaae 
GA222ittingdistribudoosyitemHA100. Thiiembodimemiinowdeacitod. 
Fig. ICBistblockdiagnmiUuatmtintatfirtribiitkm^yiM 
pHXidedatiibiaeQA222. Referring now to P(g. 103 vtUdatioametfiodaGoald 
be atond in a Bepaiaie data file JA104 QlluatiaftBd in Rg. 101) or in matter 
databaae HAIO^ Bditor/oompller JA104 b uied to create and/or update 
validation mediod u was dlacuaMl above whb nfeienoe to atqu to J A2Q2 
diraHghJA306(Fig. 102). HQweverJnthUentedln»m«dlitributkmqfa(em 
HAIOO ia reqmialUe lor making the updaM to p-code databaae JA222. 

Distribution ayatem HAIOO operates as diacusied above in the 
Distrtokm Section of diit dooomem. DistiftNidoo wflsm HAIOO allows 
JAt04 to update maser databaae HA106. Chai^ to master database HA106 
am provided to dlstrBmiorHAlOS. Distrfliutor HA102 dien ii responsibte for 
distributing the changes to the appropriate databases; m this case, the database 
to reodve die cfaai^ Is p^ode database OA222. DIstribuior HA102 
perfbnns the same chaqge to p-oode databaae GA222 as wu npde to master 
database HA106. These changes oouM be made to a call process databaae 
server JA106. 

Becauae the methods are stored and maintained In p-oode database 
GA222, changes to die manner In which calls ait validated can be 
implememed simply by updating |hoode databaae GA222. Changes in 
valldadon methods are tnui^iarent to operatic oontoles AB108. When 
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opeaior oonaote requests B valkbto 

the p-oodD and perfonu t valMtthm u dicuned above in the validation 
mtioo of thii document. If tlieniediodchanpt, die p-code is updated and 
die opentor oooaole need not chaiie die way in which it itquestt the 
vaSidatioa. Thus. ctaiQBs m die validation medtods do nMrequimqp^^ 
software in ddwr die validatmi system or die openttor ccmsoies lo be edited 
and recompiled. Asareaalt. dioaesyrtemsdoDotbavetDbetakendownto 
mke valldadon nierti od changes* 

Gall piQCMing wiPm AB1Q2 includes a bUUng v>tem AGIOS fbr 
mdog die oust irf calls and servkes, and feneiadng bills lo bill sidMcribers 
AA114 of call processing system AB1Q2. Billmg qfstem AO108 is now 
described. Fig. 104 is a bitfi-level block dh«iim ilhistiatii^ billing system 
AGIOS and its interboei lo opeiator amsoles ABIOS and NCP AB104. 

Referring now to Fig. 104. billing system AGIOS includes a mting 
^yMm, a mte file LA132. and a ti^l file LA134. Rate file LA132 stores late 
infbnnadon fbr kM^g-distance calls and services. In one etnbodiment, tale file 
LA132 can store diffbrem rate strocmces fbr each user AAI06 and/or 
customer AA 1 10. Dqiendii^ tqxm die type of ladng used, lates can be stored 
in rate file LA132 based on die distance over wUch die call la bdng placed 
(in odier woids, die distance between orig)nadt\g user AA106A and 
lerminadng user AA106B). and die dme of day die call b being placed. Rates 
are typically stored per unit dme, dius, rates can be determined as die cost of 
die call per unit time (fbr example, cents per minute). 
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For odier types ofcdit, flat meet imy be enblii^ Ataneiainple. 
consider '900** calls where an oiigiintlng user AAICMA dials a 900 4 
miniber. In this case, the user is typically billed at a ftet me (lor example, 
see per call). The flat nue is fixed and can be iodependeia of call diaoutte, 
5 die droe die call is placed, and die dtuadoo of die call. 

Raft file LA132 also stores lates at bota die wholesale levd and die 
letaillevd. Wholesale lates are die latesdnused to custonerAAUO. Retail 
rates are dwse rates diat customer AAUO chatges ita subserflKis (nam 
AA106) and die fates diatadirectsulMerter user is chaifed. 11iua« different 
10 niBS can be estabUshed at die wholesale and reiaU levd. Vnnleaale^ 

timiqg is fidly described below widi relmnoe to F|g. Ill 

Toll flk LA134 U used to store bill infbnnatkm for bm^ kmg- 
distance customer AAUO. Thb bill i nf orm at i on can indnde on n percall 
bans die wholesale cost of die call, die muoA cost of die call, and taxes levied 
15 on die call. Additional information stored tn tdl file LA134 can inchide 

infonnattoovefiardiiv how the stored latBS were oompuiedte each This 
aids in answering billing tfuesdois and trouMeAootiqg anomaltes. 

Radng lystem LA102 accesses rate file LA132 to determine die rate 
infvmnation LA124 to rate a particuter call. Ratiqg Qfsiem LA1Q2 uses rale 
20 informadon LAI24 to calculate billii« tnfbrmatioo LA126. Rating ^^arem 

1^102 dm sends billii« Infbrmadon LAI26 ID toll fite 1^134 to subset^ 
billing to subscribers AA114. 

Thm are two primary scenarios hi which blllhv system AGIOS retes 
a call. A first sorario is where Ulling ^stem AGIOS has requested it to 
25 provide a RATE QlXyrELA132. A second scenario is where Wting system 

AGIOS ntes a con^leted call based on a BIR EE322. 
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The ftnt loeovio of nting t ctll in itspoine to a lequeti fior a me 
quote U now ducribed. Rg. IQ5 is t high-level openiional flow diagnun 
illuttnttng latiQg and ctllin die rate quote loenaria Referring now to 
Figs. 104 and 10$, In a step LA2a2, an opeiaior console AB108 sends a 
IUTEQIJOTERfiQUISTLAI32toiatiflg«ystemL^ RAIEQUOTE 
RGQUE5T LAI32 includes Inftmnadon tequiied eo lan die call. This 
information can include infbmuttkm such as called party number* calliog party 
nunter» customer AAllO idendflcadon, and odier informstioQ. RATE 
QUOTE RBQUEST LA132 is a mesiage asking a rating sy«em LAIQZ lo 
rate die call as Uitad in die EATE QUOTE REQUEST LA132. 

In a step LA204, rating ^stem LA102 retrieves rate infonnadoo 
LA124 based on the information provided in RATE QWTE REQUEST 
LAI32. fonon-pQ8taliiedntBS,ndngqfSiemLA10SoonipuiBsdiedlsauioe 
using die vertical and horiiomal ooordinues of die originadi^ nunter 
and die callH number kntiQii. Non-postahied rates, inter alia, are discussed 
in die Billii^ System Methodotogies Secdon of diis documem. 

In a sicp LA206, latlng system LA 102 sends a RATE QUOTE LA 1 34 
to operator console AB108. RATE QUOTE LA 134 is typically provided u 
a coa per unit time. In odier words, RATE QUOTE LA134 is usually 
quoted in cents per minute. 

Tlie second scensrio wherein a call is rated in response to a BIR EE322 
is now described. Fig. 106 is a high-level operational flow diagiam 
illustradng the steps involved widi rating a call in respome to BIR EE322. 
Referring now to Figs. 104 and 106, in a step LA3Q2, NOP ABI04 sends BIR 
EE322 to rating ^fstem to LA102. In one embodimem, this occurs whm a 
call is terminated and BIR EE322 is updated widi die time the call lerminsted. 
Thus, BIR EE322 includes all necessary infomtttion such as calling party 
number, called pany number, start of die wholesale timing interval, ssan of 
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the lelail limim Interval, and the dm the call wu fierminiBd. In one 
embodioieiit, call duratkm, both wholenle and letail. Ii oon^MtBd by NCP 
AB104. In one embodtmem. tbii it acoompliM by BSRVR BA108. In an 
alternative embodinem* call duntion is computed by ntiog t^mem LAIQZ 
5 bated on din time wboletak timing narted, leiail tmring tMBC*. and die call 

tcnninated as indicated in BIR EB322. 

In a ttep LA304. ruing system LA102 ictrieves rate infonnation 
LA124 for die call. Again, nte infmnation LA124 can be based on the 
oriiginttiqg user AA106A, customer AAUO, d» dtstanoe over whkh tiie call 
10 was placed, the time of day, and die diuatioo of tiie call. 

In a step LA306, tiie cost of tiie call is co mpl et e d based on die late 
infonttstion, and the infonnation in BIR EB322 (for eunple, start and stop 
times of the call). The cost can be computed at die wholesale and retail laies, 
and taxes can be inchidedwitfi die call. This information is ioduded in billing 
15 information LA126, In a step LA304, bilUi« information LA126 is sent to 

toll file LA134. 

Additional feamies can be provided to blUing system AQlOSas is now 
lUscussed. Fig. 107 is a block diagram lllustratii^blllfav system AO 108 witii 
additional fonctiooality. Referring now to Eg, 107. a rate file queue LA4Q2 

20 is used as a buffer to store billing information LA126 in tiie event toll file 

LA134 is busy or cannot accept billliv infdnnaticm LA126 as qukkly as it is 
sem from rating sysem LA1Q2. A back-end LA404 momtors rate file queue 
to see whetiier Itilling information LA126 has been stond in rate file queue 
LA402. When bi11ii« informstion LA126 u stored in rate file queue LA4Q2, 

25 back-end LA404 ittrievcs diat billing infivrmation LAI26 and sttnes it is tfie 

appropriate place in uA\ file LA134. 
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In one embodiment, it nu^ not be optimum to indude aome or all of 
the tax infonmtkm in ate file IA132. In (hit embodlmem, a tax praoeduit 
LA406isindwledtDCom|HitethetaxinfiDrmatkm^ Anexaropte 
of tax procedme LA406 is die oommerdally available firom Vertex qniem. 
The Vertex wymm it available fimn Veitex» Inc., Berwyn« PA, USA. Tut 
procedure nuy have an associated datrinae or dataflle 1^408 to «^ 
Infonnatloa LA422. 

In dm event diat rale file <|ueue LA4a2 is flill and can no longer hold 
additional bmng inlbrmadon LA126. diisaddidonal billli« it^snnation LA126 
issmlfascklDNCPABIOi. In tfils cue, NCPAB104 retains this data undl 
it can be later sent to toll file LAI34. 

One fbanire of call prooessiog system ABIOZ is diat It alkwra calls id 
be nued In real dme. Thus, while a call Is in progiess, dntt call cin be rated 
at any point duriiv die call. Addidonally, as soon as die call Is terminated, 
die final rate, bodi wholesale and relail, for die call, can be oomputad. Now. 
die subscriber AAl 14 can be billed for die call u soon u It oocurs. A high- 
level discusdon of how calls can be nued in real dme is described above widi 
refBrenoe to Ftgs. 104 and 10(k 

A detailed descrlpdon of leal^me radng in mqponse to a BIR BE322 
is now described. BIR EB322 can be sent from NCPABlOi to request a rate 
or from operator console AB108 to iequeaaRATEQUOTELA134. Indie 
case of BIR EB322 sent from opemor console AB108, BIR EB322 oon^rises 
a KATE QlXnC REQUEST LA131 

Fif. 108 is an opecadonal flow diagram illustradqg die manner in 
which billing system AGIOS prices a call when a BIR EE322 was receh«d. 
Referring now to Pigs. 107 and 108, in a step LD1Q2, rsdng system LA1Q2 
receives a BIR FE322. Receipt of BIR EE322 triggers rating system LA1Q2 
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tonte the call. At memiomd above, BIRBE322oKWiaini all the hi^^ 
nwyw i i y to iste the call. 

In a Acp LO104, rating ^ttem LA1Q2 oompulEs the call JurisUctkm. 
In atep LD104, radqg lyilem LA1Q2 kioki at die locati<m<4'onKinitiqt itaer 
AA106A and the location of terminating uaer AAlOtt. This infonatioB is 
used to oonqMHe the distance over which the call b to be voitted. Thistt|»is 
only perfbnned where the rite b based on the distanoc of the call. In other 
words, this step is only performed where a non-postallaed itte structure is 
used. 

In a step LD106, iitii% system LA1Q2 first determines the wholesale 
oostof thecalK The wholesale cost can be detennined ftoin die tiine the call 
enien call prooesnng system AB102, fnmi die tiine cdl attdOo AA142 enters 
nudrix switch AB106, die time audo AA142 eitteii operator console ABIOB, 
or any odier time defined. This time can be defined uniquely for indiviihial 
men for AAI06or incBvidual customen AAllO* An eamnple is ilhistnted 
inFig. 112. The manner in which die wholesale cost of die call Is determined 
ii described m more detail below widi reference to Fig. 109. 

In a step LDIOB, rating system determines die cost of die call at die 
retail level, in one entedimem, die retail rtte is determined firni die time 
die call is oon^jileied to terminating user AA i06B until die time tiiat ddier user 
AA106 haitgs the phoiie« or otherwise teiiuiuaies the c onn ec ti otL The 
manner in whidi retail call rating is perfbnned is descnbed in move detail 
below wtdi tefetenoe to Fig. IlL 

In a step LDl 10. nting system LA 102 sends billh« Infiwmation LA126 
to toll file LA134. As discussed atbove, in ahemative embodimemi, billing 
information LA126 may be sem to toll fileLA134by wayofarviefilei|ueue 
LA402. 
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Ritiqg sy^em hu ocmipleled the ntiiig for that particular call and 
coMiDiieslD monittir LAN LAIU to itcdve vkUtuml BIRa BIR BBXB. If 
an addldoiol BIR EE323 is leodved, te radng piooett begtni Mffdn at «ep 
LD104. 

The manner at which lating syalero LAIOZ detenninei the wholeale 
fate for the call b now described. Pig. 109 \u an q)ecatk)iial flow diagnun 
ilhistiatiiv the maimer in whkdi latliig lyatan LA 102 de^^ 
laieof thecal!. Ftg, IlOisadiagnunilluatmtiivtheiatBiforcaltosttMed in 
laie flte LA132. 

Reforriog now to Pigs. 109 and 110. in a sttp LD203. xt^ng q^tem 
LA102 retrieves a wholenle iiibound tate LEMI2 OHustiated hi Pig. tlQ) for 
thecal!. WlK»lesate iidKMind nie LB2Q2 is die tafiB at which the ci^^ 
bUled wholesale, to customer AAllO, ftm die dme die whtdesale radng 
period begins (when die call teaches calKpraoessing system AB1Q2, operator 
console AB108, or terminatlog user AA 106, as discussed above). If wholesale 
inbound mte LE202 is not found (declidon block LD204), in a step LD206, 
BIReE322UputinaremieflleLA4360llustntedinPig. 104). BIRsBE322 
stored in rente file LA496 can later be praoessed agtin. In an alternative 
embodiment, neiate file LA436 Is not used and a defoult rate is emend. 

If wholesale ibbound nie LB202 is found in ate file LA132, the call 
ts mied at die wtolesale inbound rate. The rate can be based on dte inbound 
stsn and stop times included in BIR EE322. For example, die rate may be 
cheaper for calls made after 11 p.m. This occure in a step LD208. 

If BIR EE322 indicates diat die call to be rated is completed (dedaioo 
block LD210), billing information LA126 is wiioen lo toll file LA134 as 
discussed above widi refeienoe to Fig. 108. At tfiis time, only wholesale 
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infonnatkm is included in billing in(brmii1cM LA126. and dimlbre only 
whoieale coit Is Included in toil file LAI'j4. This occurs in a step LD224. 

If BIR BE322 Indicates that Cbe call is omqileted (dedsiOD block 
LD210) die wholesale oudxmod cost for die call can be corapuied. This It 
now described i^difelbrenoe to steps L0214-1J>224. fnasiepLilZi4, the 
wbidessleoudxwnd rate 1£204 Is Ktrieved from ndefi^ Thisiathe 
per uidt late die wholesale outtxmnd call will use to deiennlne die wholesale 
outbound cost of die calK 

If wholesale oudxwnd rate LE204 is In nle file LA1S2 (decision block 
LD216). in a step LD220, ndm system LA102 detennlnss what dundon m 
use to catB die call. In a step Lil222. die wholesale otdbound cost of die call 
is oonqxiled using wholesale ottdwund cost LB20i and die duration of die calL 
Ina step LD224, die wholesale oudmund rate is hulnded inbiUiqg Information 
LA126 and seid to uril file LA134. This oocuit as is discussed above widi 
r efei tn ce co step LDl 10. 

If whole oudiound rate LC204 was not in laie file LA132 (decision 
block LD216K Ina step LD206. BIR BE322 Isput in imie file LA436. 

Periodically, BIRs in leraie file LA436 ate retrieved and die ndng 
^stemLAlCQ attempts to rate die calteagvn. AHhough munenws Qfpes of 
cnors may result in a rate not bdrig oompitted and a BIR EE332 beiitg stored 
in reralB file LA436, most oommoidy, BIRs EE322 end op In rente file 
LA436 because rate infbrnttiion 1^124 was not found hi rate fite 1^132^^ In 
diis case, when diese BIRs EB322 are rerun dinwigh ndng lysMi LA102, a 
rate can ofien be sucoessftiliy determkied by enierii^ die comet rate 
informatkm LA124 in rate file LA132. In diis manner, calls diat were 
previously unratable (far example, due to die lack of rate information LA124 
in rate file LAi32) can be rated and kmg-distanoe carrier customer AAltO 
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billed for the oil. Otheiwis^ the caU would have to go uiibUled and a flat 
me would have lo be compleied. 

The manner in which the cost of die call is determined at die retail 
level (itep LDI08 In Pig. 108) is now described. 1%. Ill isanopeiational 

5 flow diagiam illus&atlQg die manner In wIM die retail rate of a call is 

deteradned. Refening now to Figs. 107 and 110, in a step LD302, nting 
syfiem 1A102 retrieves letail rite LB206 (1^. 110) from rate file LA132. 
Retail rate LE206 ts used to iite die call at die retail level. Typically, die 
retail lite Is applied to the call fmm die time die call is completed (in odier 

10 words, fitom the dme origmsting user AA106A is connected to terminadqg 

AA106B) until tfte call Is terminated. Tliat is, until ddiN user AAlOSAeidier 
hsngs up or terminates die connection, or die connect i on is terminated for 
some other raason. 

If retail rate LE206 fix die call is rat fbund In rate file LA132 
IS (dedsion block LD304), BIR EE322 is written to relate file LA436 In a step 

LD306. As was die case widi the operation of conqnidng wholesale costs, 
these BIRs BE322 In renue file LA436 are saved and can be rented later 
when retail rate LE206 for die call Is entered into rste file LA132. 

If, on die odier bsnd, letail rate LE206 is fbund in rate file LA132 
20 (decision block LD304), die retail cost of die call ursted. As widi wholemie 

costs, retail iite LE206 can be set on a per-user AA106 and per-customer 
AAIIO basis. 

In one embodiment, taxes inay need to be MkM to the retail nte of die 
call. Tu mte LE208 may be found in late file LAI32. However, in an 
25 alternative embodiment, tea nte LEMM is not included in tate file LA132 and 

must be obtained form anodier aouice. In diis case, rating system LA1Q2 
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aooeaan tax module LA406 id ittrieve lax late infimnadon LA422. Hiis 
occurs In a itq» LD312. 

BUIing information LA126 which indtidet retail ooiu and may indude 
a tax, whm applicable, ii lem to toll file ,LA134 u deicribed alwve with 
itfeienGeto«epli)110. Thii occurs in a dep LD314. 

Thus, step LDllO, wherein bill infonnadoo LA126 is lem to toll file 
LA134 can actually occur in several lepamtB inttuioei for each call. In a 
piefeired embodiment, billing Infonnation LA 126 ta nmply a data leoord that 
indudei the latii^ of the call. Thit rating can inchide a wboleaie inbound 
tadi^, a wholeale outbound rating <v a retail rttii^. 

As discussed dwve, an additional scenario in which mtii^ system 
LAlQZmtesacall Is where operator console AB106 PMpiests a rate quote by 
sending RATE QIN)TE REQUEST 1^132 to fating lystem 1^102. In one 
embodiment, RATE QUOTE LA132 inchides die same t)pe of infonnation 
tnaBlRBfi322. Inotfier words, diis Inchides information such as originating 
number, terminating number, originating user AA106A identifkation, 
customer AA 1 10 identiftestion, or any odier information requived depending 
on die parameters used to rate die call. Once RATE QUOTE LA132 is 
received by rating sytiera LA1Q2, die process by whidi rating system LA108 
computes the rate quote is die same as die manner in wluch ntiog system 
LA102 computes die wholeale rate for a call in rtgionse lo a BJR EB322 
recdvcdfhmiNCPABKM. This is folly described widireforenoe to F^. Ill 
in steps LD3Q2-LD312. In dte case ofa RATE QUOTE REQUEST LA132, 
however, billing information LA126 is nol sem to toll file LAI34. This is 
because rstiitg system LA 102 is only pnividir^ a quote for a me of a call to 
be ptaoed, and is not rating a oompteied or terminated call. Thus, for quotes. 
In a step LD316, a rate quote response LA134 is returned to operator consoles 
ABI08. The nnnner in whidi die RATE QUOTE LA134 may be used by 
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call piooesilqg system AB1Q2 to rate & debh cant call Is deaerlbed In die 
Real-Time Billing Synem Examples Section of this document 

4.2 moMf mrfJMitf IMv 

Rating vflom LAld uses lutmeroua docka to allow flexiblllqr when 
computing bills for the calls. Pacaiue of this, rases can be ccHDpuied for 
wholesale u well u for retail. Additional^, die dmes at whkdi Ulllng slam 
for wholesale and retail laies can be defined difRBiently for individul users 
AA106or for individual custtMners AAIIO. 

A piefonod embodiment Is now described In which blllir« (br die call 
at a wholeiale rate can be started at diree dlfforem times, and Mlling for the 
call at the reddl rate Is always staned at one dme. Fig. 112 is a diagram 
llhistiatlng times for which wholessle and retail bills are omnputed in one 

RelOTing now to Fig. 112, when die all enters call processing system 
ABIOZ (box LL1Q2), in odier words, when call audio AA142 b routed to 
matrix switch AB106, a first wholesale clock LL162 is started. This is shown 
byaboxLL122. irwholesaieclockLL162isu8ed when billing die call, die 
wholesale tale for that call is applied fhrni 'time T equals wo* (T«Q) umil 
die call terminates, as shown in block LL 1 10. Tbe call terminates when eldier 
user AA 106 haqgi up, or odierwlse lenninatts die oonnectkm. or when odier 
factois force the oonnscticHi to be broken. 

A second wholesale dock LL164 Is slatted when call audio AA142 is 
routed to an operttor console ABIOB. as illustrated in btock LLI04. This 
occurs for operamr-assisted calls. If die wholesale bill is to be completed 
MOAvg start wholesale clock 2, die wholesale rate Is applied to die call from 
time T » 1 until die call terminates, as illustrated by bkick LLl 10. 
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A thiid wbolettle dock LL1« b ituied when all audto AA142 Is 
routed to the deidnation u illiutrated in booi LL10& For cells id be billed 
wholesde ftom this time, die mte is applied to the cell ftom tone T « 2 until 
die call lenninaies, as indicated by Mock LLIIO. 

For oomputing the letail Mil, a ntall dock LL168 Is started when 
teminatiog user AA106& answers die call and NCP ABJ04 receives an 
answer message BDU8. ThisisillustntfedbybtockLLlOS. Intfiiscase^ihe 
r^l bill is oomptMl by applyiitg the retail rate from time T 3 imdi tbe 
call terminates at slaps, as indicatod by block LLHO. 

There are numerous ways the wholesale and retail docks can be 
implemented. In one embodiment, the docks are not timeii ferae, but the 
call is timed using time marfcen and oomputing the dme between the maifceiSi* 
For exampte. for retail billing, when tenntoating user AA106B annven at 
dme T * 3, and NCP AB104 receives an answer messase, NCP AB104 
updates die BIR EE322 for die call to indicase die time at which die answer 
message i> received. Similarty, when the call tendnaies, NCP ABlOi notes 
diis time in BIR BE322 fbr die call, 

Widi these dmes noted in BIR EB322, nling system LA102 can 
conqmtt call <hnatton LL142. Rating system LA102 caii knm whidi dodi 
10 use based on infbrmadon contained in nte file LA132. This informadon 
can be uniquely identified for differem users ABI06 and difViBrem customers 
AAIIO. 



dl J JM Iif i^g ^ftitM MirthfidMfljgiif 

The various billtiig medioddogies diat can be provkled by call processing 
system AB1Q2 include: 
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• Poit'ptidt pcntiltsBd 

• Pott-paid, noD-posiallaed 

• Vm-^ with credit Umica. puiAlized 

• Post-paid wUh cradh llmin, nonposttliied 

• Ptfrfaid, pomliad 

• Pie-paid, ncm-poitalixed 

Fou-pdd implies tiwt chaises accumulated by the accoum aie billed to the 
dient after die diafgea were incurred; eg., monthly, biweekly, etc, 

lYfrfotf impties dut services are paid fbr in advance. As the service is used, 
it is chaffed against the preiMid aooount'a positive balance. 

Usii« a postaUzBd rate ttnicture, billing is baaed upon a pre«t late per unit 
of time (usually minutes) not vaiying by mileage; for example. 20 oema per 
mini^. legardless or whether a call is fhrni Cedar Rapids. !A to Iowa City, 
lA (H' from cedar Rapids, lA to New Yofk. NY. 

Under a mm-poMUigd rate structure, billing la baaed upon the dollar value of 
die service, which la variable by distance and time of day. Thia meana that a 
call from Cedar Raplda. lA to Iowa City. lA ia liWy to be leas expensive than 
one from Cedar Rapida, lA to New York. NY, even though die duration of 
both calls is Identical. Non-postalixed rate atructurea may incorporate 
combinations of distance charges and time of day charges. 

Pre-paid canb alkyw callers to make long-diatanoe caila or use enhanced 
servicea auch aa messa^ng, conference calling, speed dialing, or audtoiext by 
charging die calla or aervloea against a prepaid aocoum*a poaitive balance. 
Two basic types of carda are available *- one diat almply expires when its 
value is depleted, and one duu is "rechargeable/ The system has die ability 
to track calls in progress, interrupt calls to alert die caller of diminishing or 
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remaiaiog dme or value, and aUow callm to itplenuh the baluoe. Itm 
system alio will provide a wamiqg and tennlnate calU wboie dme or dollar 
value taui been exhausied. 

Both preiiald cards and post-fitld .anb with citdit limits are sid^ect id cips 
on Individ ual services and on certain desdnation munbevs, A masdnmin anoum 
of usage Is allawed for eidier a specified pmd of time or a dollar value, as 
opdoned by die card issuer. 

DMCmd 

Fig. 1 13 is an openuional flow dii^giam illustratiqg the sttps involved 
in perfbrming real-time billing for a debit card call. Hg. 114 is a data flow 
diagram illustrstbig die data flow duu occurs durii^ real-time billmg of a call 
placed using a debit card. 

Referring now to Figs. 1 13 and 1 14Jn a step KA1Q2, operator oonscde 
AB108 receives dse debit card number KA222 to which the call is to be 
charged and opmtor control data AB124. Operator oonorol dsia AB124 is 
recdved from NCP AB104. Operator control data AB124 includes 
information ^xan die call regardiqg die type of call bdqg placed (operator- 
assisted), and die destination of the call 

Debit card number KA222 is ^ically pnmded by ori^nadng laer 
AA106A to operator console AB108. This number can be ottered using a 
touch-tone ^kmt to a VRU AB134. Alimadvdy, die number can be 
provided to a manual operstor console AB132 verbally. 

In a step ICA104, operator consc^ ABI08 determines the rate fior die 
call and the dollar amount remaining on the debit card. Determining die rste 
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is acoompllflhedu described alKyve with lefe^^ 104. lQ5,and 106. 

To idientD, openlor oonsole AfilOS sends a RATE QUOIV RBQUEST 
LA132 K> billii« system AG108. RATE QUOTE RBQUEST LA132 
includes Intomitkm needttl by biUiiQi^^ a mte for 

ttecalK BecaiMcailiadi^canbecustDndiedforspedflccusiDmenAAllO, 
or usen AA106, the informadon needed by bilUt^ system AGIOS in 
ooniputiqg a rate quote will vaiy based on costnnm AAl 10 and user AAl^ 
Typically « the information used to detennlne a late can include dw time of day 
that die call is being pieced and« for distance-dependem nues, die ot^gin and 
destination of die call. 

Billii^ system AG 108 then computes a fate for die call in terms of cost 
per unit time. This mte can be oonqmted in a number of <fiffimm manners 
depending on the embodlmem of billing system AGIOS ImplementBd. For 
enmpte« die laiB can be coiiqittiBd by performing a simple tabte look-Hip u^ 
dietimeofday. This worin well for a postalbed rale soructiire that varies for 
different calling periods but not l^mile«|p. The rsie could also be computed 
using calcuhtttons to determine die distance of die call and multiplying diis by 
die rate per distance establithed for tint customer AAllO or user AA106. 
Thb works well for a ntm-posodlaed mie structure where billing is based on 
die distance and die time of day. Numerous alternative embodlmems could be 
implemenied, including one tint uses a combination of odile look-ups and 
calculations to compute die laie. 

In a step KA104, blllii^ system AGIOS sends a rate quote response 
message KA134 to die opentor console AB108 diat icquested die noe quote. 
Rate quote response mesnge KA134 provides die rate ai which die callls to 
be billed. 

Fig. 113 is an operational flow diagram illusuatit« die steps involved 
widi determining die remaim^g doltar amount on die debit card. Referring 
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now CD Hg. 115 Jn a «ep ICA402. a REMAINING DOLLAR AMOUNT 
RSQUEST KA228 u lem to a debh cud dm baie 1CA272. 

In a stqi KA406, the lioltir amount lemaioing on the debit caid is 
retrieved ftom debit cafd dttbaie ICA272. 

S In a step KA4W. the dollar amoiimiemaimiv 00 die detect 

to opeffitor comole AB108 in a REMAINING D0LL4R AMOUNT 
RESPONSE meange KAm 

Retumii^ now to F(g. 113. in a step KAI06, die call is validated by 
validadon qrtieni AG1Q2 where required. For example, the particular debit 
10 caid may be vatidated to detennlne whether it is vaUd for ptanm calls to die 

attempted destination, from die originadi^ locatkm, or other like call 
chamcteriitiff^ 

In a step KA108, debit batch inforaatiaa iCA206 is retrieved from 
debit card datsbase ICA272. Debit botch inftwinatioa ICA206 provides 
15 inficirmationn^anlingdK debit card bdni used, such as what alem top 

to orifinaiint mr AA106 refwdlng die amoum of dme temaining in die call. 
Debit bfich information KA206 can also includes i nf bn nati on regardii^ how 
to alert (voice or lone), how to rate (flat or rate qyoie)* how lo expire, 
termination mediod, etc. 

20 Ftg. 1 16 is an operational flow dtastam illustming the steps invblved 

widi retrieving ddnt batch infomatkm KA206. Referrim now to Fig. 1 16. 
in a step 1CA502, operuor console AB108 sends a mm RATCH 
INFCHIMATION RfiQUEST ICA232 lo debit card database KA272. 

In a step KAS04. batch information KA206 pertaimi^ 10 die debh card 
25 used 10 place die call is retrieved from debit card daabase KA272. 
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in a «q» ICAS06, bitch information KA2^ 
AB108 in a WKR INRHIMATION RESPONSE KA234. 

RetunuQg now to Fig. 1 13, in a oep KAl 10. opeiativ oonaote ABIOB 
determines whether the dollar amount 1CA206 remaining on the deUt card is 
sufficiem«>ooni|ileie the call. In one mhbodiment, operator console AB108 
simply determines whether Mhr mount KA206 is sufficient lo pay for Che 
call for a specified minimum call dumtkm at the quoted ntfe KA2Q2. 

If dollar amouM 1CA206 Is sufficient, in a snp KA112, opentor 
coMole ABlOe sendsa CALL READY MESSAGE KA236 to NCP AB104. 
CAIX READY MESSAGS ICA236 instructs NCP AB104 that the call may 
becompletBdiDfliBdestinstioB, In one emlNNHmem. this is aoconqiHBhed by 
opemtor console ABIOB sending opmtor re^Mmse data AB126 to NCP 
AB104, wherein operator reiponse data AB126 comprises CAUL READY 
MESSA<% KA236. 

In a Step KAl 14, NCP AB104 completBS the call. In this step, NCP 
AB104 sends switidi control data AB142 to matrix switch AB106, instructing 
matrix switch AB106 to route die call to die desdnadon On odier words, to 
desdnsdon <yntch AA104 and/or termlnadng user AAlOdB). At diis dme, 
origiiisdng user AA106A can communicate wtdi termlntting AAKVSB. 

If in step KAl 10 operaior ocmsole AB108 had determined duu dolhir 
amoum KA206 Is not sufflciem to ooti4>lete die call, operator console AB108 
takes die steps dot are now described. Hg. 117 Is an operadonal flow 
diagiam illustradng die Aeps taken by operstor console AB108 when dollar 
amount KA206 is insufficient to compleie a debit card call. Referring nowto 
Fig. 1 17, in a step KA6Q2, operator console AB108 informs originadng user 
AAlOdA diat die dcdiar amount remaiidng on die debit card is insufRciem to 
complete die call. This response can be provided to originadng user AA106A 
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by a human apmior at a manual opetaior oonaole AB132. Alternatively, the 
responie can be a recorded or lymheaiaed mei^ge played to origi nath^ uier 
AA106A by a VRU ABI34. Custom icriptt may be ued in genentli^ the 
reqxmse ao that origimting uier AAt06A ii provided with a cunomiad 
5 feiponse such as calling die uaer AAI06 by name or identifying the name of 

carrier AAllO to which user AA106A subscribes, or identifyiiig the name of 
the debit card. 

Ina step 1CA604, originadng user AA106A is provided with altemttive 
options Oat may be pursued in completing the call. These options can include 

10 recfaaiging tiie debit card, where avaitable, and pkciqg die call by odier means 

sudi as using a credit card, usii^ anodier calliiv card, or ptactng a collect 
call. Again, die options provided to user AA106A may be costomiaed for 
Individual ori^nating usen AAIOM or eusttmieis AAUO. Scripts are used 
to provide tills customiation. Fbr example, where a manual operator oonaole 

IS AB132 is handling die call, a script appears on die opeiator screen. The 

operator reads the script to origlnatii^ user AAI06A. The scr^ provides tett 
to the operator oudining die options for diat particular user AA106A or 
customer AAllO. 

In a step ICA606, If originating user AA106A does not chooae to 
20 comptae die call using one of die provided options. In a sttp KAttlB, die 

operator infiDnns die user diat die call cannot be placed. 

In a step iCA610, opeiator console AB108 lerminates die call. This 
occurs by sending opeiator response data AB126 to NCP AB104. NCP 
AB104 in turn sends switch control data AB142 to matrix switch AB106, 
2S terminating die calL 

If, on die odier hand, in step KA606 if an ahemative option was 
chosen, die system may dien proceed to validate die option in a step ICA112. 
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TMi step may indudecheddqg die validly of acalllng catd, acredit card. ^ 

conttcdqg the called party to detemnitie vrhedier chat party will aooepc the 

chaiges. IftteoptioniBvalidafed^ikeopmtHiaOQid 

dw call is compteisd in aiq) KM14. If, on die odier hand* the option is 

invalid, die mer is infonned iti step KAW«nd the cill is terminated instep 

KA6I0* 

The above text, with refeitnoctti ^ Haasd 114, described ital- 
time billing 10 M up a call beiig placed with a <hbit card. Goaqrietion and 
temunation of die debit card lont-^stiDoecall Is now descrM. 

GomiMng the call ihoidd be diffiBtemiBM frnm terminating the call. 
OonqpMng the call meana the call is routed ftom orfglnning user AAIO&A 
toterminatitvuser AA106B. DBmliuting die cftll means die call Is no kmger 
routed to terminatii«g user A\l06Baotl Isended. 

Fig. 118 is a data flow diagram llltotiating the messages sent in 
oompledng and teminatlng die lof *4listanoe ctll piaoed using a debit card. 
Fig. 119, which oHnprisesPlgy. 120 sad 121, leuiopenttional flow dlagmm 
ilhistrating dte steps involved is completing Basi ttrminadi^ a debit card call 

real-time billing. 

As discussed i^Nive with refeience to Fig. 113, in steps KA1I2 and 
KAI14, die NCP reodved a C\lL VEAPV MESSAGE ICA236 «id 
instructed matrix switch AB106 to rode die csll to die destination. 

Along witfi CALL RKADr MESSAGE KA236, RATE QUOTE 
DATA KA2Xn is sent to NCP ABl04 ao that die call can be billed in real 
time. 
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RefiBrnQg now lo P|g». 118 tod 119, in oonipletiqg the call, matrix 
twitch AB106 lignli Ihe call to ring at che destinatkm (at lenniiiating ner 
AA106B). When termlnatliif mer AA106B antwm the call, an anwer 
iiietage ABI34 is lent fio NCP AB104 indicttii« that the call b oompted. 
Al this time, originating oaer AA106A, and lenninating mer AA106B can 
communicate vte long ifistanoe and ictailtlndng of the call begioL Ititatthia 
point that ittail charges iMitaocniiqg for the call. This is Ultianied in siep 
KB202. 

Inas(BpKB204, BSRVR BA108 uses late quote KA202 and efatpied 
time since the call was oompteted to keep tnck of the cost of the call in real 
time. In one embodiniem,BSRVRBAl(WperiodicaUy uses rale <piolelCA202 
and die duration of the call up to that pdm to determine die cufient cost of the 
call. In this manner, die cumutative cost of die call is tncfced. 

In a step KB206, BSRVR BA 108 uses mte quote 1CA206 and remaining 
dollar amount 1CA204 to determine when dollar amouiK KA204 will be 
exhaufled. 

in a step KB208, BSRVR BAiOS toola at batch infta ICA206 to 
detennine when originating user AA lOt&A is to be alerted tiiat remaining dollar 
amount KA204 is almost exhausted. In one embodiment, only originating user 
AA106A ts alMted. This is die endmdimem described hetdn. 

For die purpose of titis discussion, we assume diat in one endxMfimem, 
alerts are to be sem to die uter indicating wha dm are 60 seconds 
lemaiitii^indieGallandwhendierearelOaeoocMlsTeroaiidngindKcall In 
ahemative erebotfiments, alerts could be sent to warn die usv at odier times 
or could be sem baaed on dollar amoont remaining. Tills fiBature is 
oonfiguiable on a per-sidMcriber or per-customer baas. 
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In a iicp KD2I0, wtai there are 60 lecxmds rematitiqg in the call <ln 
ocher woida, when lemalniog <lollar amount KA2(M will be exhausted in 60 
leoonc I), NCP BAI04 aenda an imerrapt mesnge {nfmi lo as fint intemipt 
message KB!22) to opemor oonaole AB108. In one embodiment, BSRVR 
5 BA108 sends an intenupt messate to CMP BA102. CMP BAUD sends the 

message lo host gateway BAllO and to CRD BAI06. 

U shoutd be noted tfiat when the call was completed (nxned by matrix 
switdi AB10Q» opeialor console AB108 no longer handles the call. At this 
time, cpemior console AB108 is firee to handle odier calls, and call audio 
10 AB142 fnrni the 6Mt caid call placed in dus example is no longer nnited to 

operator console AB108. 

The effect of sending an Internet message KB122 to CRD BA106 in 
step KB210 is that CRD BA106 now allocates an opemior console AB 108 to 
handle die call. 

IS In a step KB212, matrix switch ABr^ now routes call audio AA142 

diTough opeialor console AB108. This is iUustnted by dashed line RB172, 
In a step KB414, operator console AB108 provides a first alert messige 
KB124 to originatiqg user AA106A. In die embodiment described in dds 
example, fint alert messige KB124 is to inform originating user AA106A duu 

20 diere are fbverdian 60 seconds of time lemainiiig on die debit card. In one 

embodiment, during dils time, lerroinadng user AA106B is routed to a stbb 
KB104. In diis manner, terminating user AAI06B does not hear first alert 
message KB124. In an alternative embodiment, die call is routed diroitgh 
operator console ABI08 so both parties can communicaie via opetator console 

25 ABI08. 
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In a Hep KB416. the call » now nmted din>m;b o|ienior oonwle 
AB108, and originating user AA106A ii oonnected with temlnatiqg iner 
AAUWB, as Illustrated t>y dashed line KBI72. 

In this document, when opeiator oonsoles ABKM aie refened to in fhii 
manner, operator oonscHe AB108 can be either a mamiai opeiaior console 
ABI32, a VRU AB)34, or a customer ser^ console AB136. 

In a step KB418, at the time for the second akrt, in the example 
embodiment when 10 socondi are lemaiuiig, NCP ABKM sends a wconrt 
imemipt messige KBI24 to operator console AB108. In a step KB^, 
openftor console AB106 infonns origintiliv user AAltMA that the call time 
Is almost eipired. In the example embodiment, operator console AB108 
informs the user diat 10 seconds are remsining. 

In a step KB422, if usen AA106A cootimie lo talk, and neidier one 
hangs iqi, BSRVR BAIOBA sends a termini message 1CB126 to opentor 
constrie ABtOB. In a step KB424. opentt oonsoto ABKM hangs up 
termlnadqguserAA10(^. At diis time, originating user AA106A is Informed 
that the time has expired and the call wu terminated. Tbb announoemem is 
made using acr^ Again, diese scripts are ehfaer automated via a VRU 
AB134 or provided vocally by an opeiator on manual operator console 
AB132. llie scripts can be custoimaed to a particular user AA106 or to a 
particular customer AAUO. 

Alternatively, in step 1CB424, originating user AAIOM may be given 
optitHis odier dam autoinatic termination of the call. The script may Indicate 
ttiat originating user AAI06A may enter anotiier dcMt card number, or diat 
originating user AA106A may choose to continue tiie call ush« a credit card 
oracalliiQcard. Addhlonally, if tiiese scripts are being sent by an automated 
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VRU ABI34, origitttiiig user AA106A may be given the optioD to pieu '0" 
10 tpctk to an openlor for alternative aptioitt. 

This embodiinem was presented with messages sent only to originating 
user AAIOM. Alternative embodiments are contemplated wherein similar^ 
S altemative, or additional messtges are sent to terminating user AA106B. 

In respmne to first imemipt ir. ..»iage KB122, opemtor console AB108 
sends adeUtoomplete message KB132 indicating that the call Is now routed 
ttirough Qpeiator oomole AB108 (step KB216) and that originaiing user 
AA106A was alerted (in step KB2U). In itsponse to second interrupt 
10 message KB124« operaftor ocmsole AB108 sends a second dbblt complete 

message KBIM bo NCP AB104. Second debit oomplelB message KB134 
Indicates that originating user AA106A wu infmned that call time Is almost 
expired In sMp ICB220. 

In siq> Kfi224, operator console AB108 terminated die call. This is 
IS aooomplished by sending a termlnadon response KBI34 to NCP ABltM. 

Termination lesponse KBi34 causes NCP AB104 to send switch control data 
AB142 to matrix switch AB106 Instntcdng matrix switch AB106 to terminate 
thecal!. 

After the call is terminated, system aocaundng records nuist be 
20 updated. This process is now described. Fig. 204 is an operational flow 

diagram illustrating itie process involved with updating the accounting records. 

Relenrii« now to Figs. 118 and 204. in a step KB3a2, NCP AB104 
sends a BIR EEQ22 to billing system A0108. Because billli^ server knows 
the rate ICA2a2 at which die call is to be charged. BSRVR BAKM recalculates 
2S die charge for die call at periodic intervals. In one embodiment, diis interval 

is every second. In diis embodiment, the amoum duu die call cosu Is updated 
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every Kcond. This Is neirty its! tline« BIR BE132 Is lem after the call b 
oompleied and the total cost for the call hu been calculated by BSRVR 
BAIM 

In a step KB304, billinig synem AGIOS uses BIR EE132 to update 
5 aoooum records in a toll file LA 134 fillustrated in Rg. 104) for origintting 

ustf AAlOdAandcuslonierAAllO. BIR EE322 includes the cost for die call, 
die time die call was iiutlaied by user AAIOS, the time die call was oon^teted 
totermlntdnguserAA106B, and die time die call was terminated. Fromdiis 
information, billing system AGIOS can calculate wholmie and lettil costs of 
10 die call. 

lnastepKB306. NCP AB104iqNlates debit card database KA272widi 
a new remaning dollar amount KA204. This is die amount of mmy left on 
die card, if any, after die call is terminated. If diere is none left, debit card 
database ICA272 is provided widi Infonnation as to when die cud expiied. 

IS In a step KB308, debit caid database KA272 is ivdatedwididdM^ 

complete record KBi42 via distribution system HAIOO. This simply 
overwrites die record send direcdy to debit cr tt database iCA272 in step 
KBSOtL The update in step KB306 is performed so dnt debH card database 
KA272 Is tqxiaied immediately in case distribution system HA 100 goes down 

20 and does not update debit card datdnse KA272 beftne originating user 

AAIOM attempts to call bade and reuse die debit card. 

7.0 Pimi Ikttaiom ma PnPiiUhm 

Fnud detection and/or prevention is provided by the ftaud system 
PB 102 of die present invention based on messages and data reodved from the 
2S BSRVR BAIOSA, die consoles ABIOS, die billing sysmn AGIOS, and die 

validation ^stem AG102. Fraud alarms are provided to die fraud 
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idminittiitor on fnud ooiisoie(a) PB106, and aie itored in refpecdvt • amt 
files for fttled odls in FBNAIARMS PA120 and ownpleted BNUALAIIMS 
PAil6. Rcpom of fraud activity can be ptqaied. Real-tinie fmuddecoliori 
and/or prevention ii pravkkd by the pieaent invention. 

Raud in the ate of die leleplione Qfiiero Is a v^ 
today. Unautiiorind users are ifale to use the telephone Qfsiemwidiout bavins: 
to pay for such use. This constimies finud. The cost of such fhuid is banc: 
by the legitimate users eitfier directly or indirecdy. Where legal responsibility 

10 rests with the amhoriad user, the long distance carrier can charge the 

fraiidulem calte to tiK authorind user. Where legpd liability does not re^ 
the authorised user or where, for businesi reasons, the carrier deddei not to 
asress the autiiorbDed user, die cost of the fhuid inust be borne by the carrier. 
UMmattely , since thb fraud reduces die prafltsbility of the carrier, die carrier 

15 must increase its rates to its autfiorind users to make up for losses incurred 

due to tiw fraud. The very real costs associated widi such fraud In die 
teiephcme system results in substantial increases in rates tiiat would not 
odierwise occur if such Araud could be prevented. 

7.2 Specffk FmuUdtMt Mtthod ScMMmios 

20 For many years, telecommunications carriers have experienced 

problems witfi individuals stealiqg dieir services. WIdi die advent of 
computers, dicit of serifioes becaine easier Iw die crinunal, and carrm of ti^ 
sixes began to realise higher monetary losses because of fraud. 

The inventors have extensively investigated die fhuidulem mediods used 
25 by criminals to steal carrier services. A shon Uilorial on diese mediods is 
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pretented below. ThU tuioriil Mlilites an undeniiiidiiv of the i^^^ 
m et ho ds of the pretent invention designed to delect and ptevenc fnodiilent 
activities. 

Toll ftaud Is commided in a vari^ of ways, by a variety of people 
(also called crimhnls or fiaudulent uae^). Fnuid in its most basic fom is 
perpetiaied by the fiaudulent user or individual who, when tiaveling, pfanes 
a penon-to-penon collect opeiator-assisied call to his home to let hb fiunlly 
know he reached his desdnadon. This person* to avoid die loll chaifes of the 
long-distance call, will ask to gwak lo a preanaqged ficddous person, or 
himself. The fiunily has been instntcted to deiiy die call (dial is, not aooqit 
chaiges BO die call is not allowed to go dirou^) ao nochaige is incuntd, but 
Uiey know die fiunily member hu omipleied his navels. This scenario is 
peihaps the most common ^pe of toil fraud commitiBd in the U.S.A. 

The more cosdy types of fraud of tefecommumcadons services are 
committed by diree principal groups; computer hacken,organiaedcrimniais, 
and "phone phreaks** (also called idmne manipulaion). 

The computer "hacker* is an Indi vi(hial who uses a computer to bieak 
into anodier computer system or networic in an unautfnriaed oHmner. This 
bresk-in is done to get infonnadon from die oomputer, such as: credit card 
aocoum numbers; secret plans for manuteturers of computer games; and, 
sometimes even dassifted documems of g overnment defense departments. 

The term hacker has its origin m die early days of computer 
programming. The first computers were hnge machines whh very oomplicatBd 
computer programs. Companies would hire oomputer-litBrtte people to "hack' 
die computer systems to find progranmita^ ernvs dutt oouU cost the company 
rigniflcant financial knses in down-time or lost revenue due to billing mix-ups 
anddielike. Eventually, diese paid computer professionals began to cross die 
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boiden locildi« Ibr odier peaple*i oomputen and their mistakes just for "fun. 
In earty oomputer espionage cases, data was sometimes destroyed or stolen 
and soM to the highest bidder by dieae miginal hackers. 

Modem day hackers steal long-distanoe telecommunication services for 
three resi ont? 

(1) They do not want to pay long-distance charges to call into 
lemoie computer ^siuns^ 

(2) They do not want to be caught. They know that if diey place 
loiig-disiance calls dirough their phone con^nny, die call can 
betnoedbacktothem. Theft of computer services is a serious 
crime in most states in die y.S.A. Consequemly, die hackers 
want toavoU haviiv ttte calls traced back to dteir computer via 
die phone lines; and/or 

(3) They know duu dieie is a commercial market for die 
informatkm they steal from computer systems and loQg distance 
carriers. 

The second principal group consists of ofganiaed criminals. Oiganieed 
crimes, such as drug running, gambling, boiler-room operations, ami die like 
are made more profitable dirough the use of stolen credit cards and odier 
Wlliiv devices. The criminals are able to complete didr business widKHitfisar 
of beii^ traced over plione lines by law enfo rc em en t audKWities. Most 
organiad crime members do not actively pardcipalB in the diefk billing 
devices, bm diey do eniploy a nuinber of young computer hackm and "phone 
phreaks' who are willing and able to provide the needed information for a 
significant fee. 

The diird prindpal group consists of "phone phreaks.** The "phone 
phreak" matqwlates long-distance networks by a varieiy of methods. The 
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gotl is loplaoeacall the furthest distance possible without piyii^ for the call, 
and widiout getdqg caught. 

These thiee groups and otfier criminals use several difleitnt types of 
crimlml strategies 10 sMltdeoommuiBcattoa services. Someofthestniei^ 
InvestigatBd by the invauors ait u fbilows: 

Many dmes hadm call into (also lenned "rii^ t^p*) the ousttMier 
service department of a carrier and act u an employee of die carrier. The 
hacker then attempts to get information^ such as card numbers, 800 numbeti, 
oriestioaps. The hackers also may make extensive searches through a king* 
rtisianrf carrier's trish ("rubbish") lilns in an elfost to retrieve printed 
materials dttt wouM ftirdter dieir cause. Spedficalty, hadten kmk for 
traimog manuals, test luaimenanoe schedules, phooe direcKiries, business 
cards, and die like dmt have been discarded. Usii« this purloined data, 
hackers are often able to fool le^tlroate eniplayees into divulgiqg propriett^ 
infui Illation. 

"Phone phreaks" sometimes use computers or odier etectronic devices 
to acceu die kmg-distance telecoronuinications networks. The most common 
devices used are electronic tone genemiofs refcmd to as " B on es . * Them are 
several types of "Boxes" in use worldwkle. The roost popular is die "Bhie 
Box* which a tone generator packi^ inside ddier a calculator or some 
odier small boot or enclosure (the first one found was blue, which accounts for 
diename). The tones of die blue box resonate at 2600 Hz, which is the signal 
used by long disumoe switches in die U.S.A. to signal a (fiso onn ecsed call 
from the terminadog end offRce to die oiiginatiQg callii^ ofAoe. Other Q^pes 
of "boxes" include "Black Boxes," "Red Boxes," and Xheese Boxes." "Black 
Boxes" prevem answer supervidon from returning to die originadng Calling 
Offkae ((X», and dius prevem billing of die call. "Red Boxes* emufaitt die 
sounds made by omns droppii^ throitgh a pay |toie and signal to die phone 
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company to open the voice path for dialing and speaking. ^Cheese Boxes'* 
allow redirection of calls, or Call Forwarding as the term is used in tte 
U.S.A. 

Another form of telecommunications theft used frequently by htcken 
and by "phone phreaks" involves a computer program that, utilizing a speed 
dialer, allows them to dial into a long dinance telecommunication network. 
Once in a telecommunications network, an authorization code and a target 
number (usually another computer) are attempted to determine if the code 
processes the call. If the code dialed is valid, the computer will receive 
answering modem tone from the target computer, and store the good code in 
its memory. The program then instructs die cotnputer to hang up, rediaJ the 
access number again, increment the authorization code In some manner, and 
redial the target computer. This process can be set to run automatically by 
setdng a range of codes for the computer to try dialing, or by a specified 
length of time. The average program can gather one valid six-digit code for 
every eight to ten attempts. The longer the number of digits for the code, die 
longer it takes to hack. The codes are then shared or sold to other hackers. 

Another frequently used mediod of obtaining authorization codes 
involves a confidence scam or game. The perpetrator calls a consumer late 
at night and identifies himself as a security investigator with one of the long- 
distance carriers, for example. He tells the consumer that her credit card is 
currently being used by someone to place large numbers of international calls. 
He explains that, in order to stop die calls, he must have the customer reveal 
her credit card number to the *'invesdgator." Many customers do. in fact, 
give up the number, and die person posing as the inve^gator then takes the 
card number and sells it to people to place die ill^ calls. There are several 
different variations of diis scam currently being used in the U.S.A. 
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Many times these oonfldenoe gvnet ace used 
ilksal telemailcedng ventuies. The crimiial sets up a fiaudulem "fhmt" 
company and b^ns telemarioeting CD areas of die coundy , offeriog expensive 
appliances, vacations and ihe like for minimal fees. The purchases must be 
made with credit cards, and, when they get the card number from die 
customer, diey sell the number to others, or chaise dwusands of dollars of 
equipment tiatt Is then delivered to lemote locations and resole. 

Hackers have also been known to spend time st m^ metrapolhan 
aiipom or tnb stations observing cusioiners i^adng ctfb and co|^ 
thi^ Giecfit card numbers for later sale or personsi use. For example, suspects 
in New York Cl9*s Union Station have been arrested for using video cameras 
witii powerfol mm lenses to pick up people's calliqg card numbers ftom 
across the waitli^ room* 

Subscriptiim fkaud, which is defined as the imentiml application for 
services for supplying fiaudulaitinformatimi, Isafost growing problem in die 
U.S.A. This^ypeof fraud can easily cost a tel?rommunications carrier large 
sums of money in bad debt Few stales in die U«S. A. have facws against this 
type of activity, and so tiiere Is maximum gahi for minimum risk and output 
on die pan of die criminal. 'Hie n-jst common case of subscription tmA 
oocun when people SM up accounts In a resklenoe for multiple tetephone lines, 
dien sell die servkes to people on die streets of die city. When die bill for die 
services arrives, die perpetrators of die sidiscription fraud move to anodier 
kKstion, and die telecommunications carrier tfcses not know a problem existt 
until 90 days or tater when diey try to collect on die account 

As carriers have tightened dieir defenses «gainst hvker : jnd phone 
phreaks,dieseindividuabhavedirBctBddieirattentiontowardeasiei irauduient 
activities. These fnnidulem activities involve Private Business Exdmges 
(PBX's) and Customer Premise Eipiipment (CP^), which have become die 
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tatffi of massive fnudulem cunpiigns by the crimiml oommuntty. Muqr 
PBX*s for example, have 800 nunten for mcoming Direct Inward Sysm 
Access (DISA), whidi allows the ownen of the PBX to make loqg^lisuuioe 
calls ftorn lemoce locations, with billing to occur ftom tbeousiomer's PBX. 
The criminals have diacoveied how to access these DISA trunks, almost 
undetected, and have placed millioos of dollars (U JS. A.) worth of fraudulent 
long-distance calls. The kmg-distanoe carriers are holding the equipment 
owners reiponsible for the charges, and the equipment ownen often have no 
recourse fbr recovery of dieir losses from die criminals. 

Many equipnwnt owners are not even await that ihey have the DISA 
functfamin didr eqdpment, and so are cavghtconiplelBly unaware when did 
phone bUlisrecrived from the k»g-dtsttinoe carrier. Bqu^miemowtKfshave 
been billed fbr as much as U.S. $1 million for fkauduknt calls made duoogh 
thdrPBXs. Hrst tier carriers are now taunchii^m^Jarcaniiiaisns to educate 
the business community on the dangers of raX fraud, and are even offering 
"Insurance" ptaua of service In case of an occurrence of fraud. 

Voice mail ^ysienu (VMS) are also a cominni target <rf *phteaks* and 
hackers. They take over a company's voice mail system, and change all die 
user boxes Into "code lines." The criminals post stolen ainboriaation codes 
and credit cards on the VMS, and hackers call In and retrieve the informatkm 
for tfadr own criminal uae. 

The research of the inventors reveals that the most omunon 
popetmors of teleconunumcations fond are usually found in <me of three 
groiqw: 

(1) College sdidatts; 

(2) Prisoners in prisons, and Inmales of mcmal institutions; or, 
0) Military personnd. 
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These three groups of peipetnlare of teleoommunkatbiu fnud have 
a number of things in common: 

(1) Limited access to money to pay large phone bills; 

(2) Far fhmi home and fiunily; 

(3) Ready neoess to infbnnation and personnel to ftiilher scams and 
schemes; and/or 

(4) The desie to dicumvem die system. 

College students usually are involved in sthemes to defiaud phone 
companies dirough opentor^osi^ calls. College students illegally use 
calling cards bekn^ng to otfiers to ptaoe dirir calls, and often post the cards 
on pay phones around the college campus. Their goal is to have so many 
users on dse cards that die phone oonqiany will not be able to trace diem all. 
They are also often guilty of ptadng diird paity-Ulled calls widiout permission 
or authorisation. 

Prisoners have pcrfiDcted the art of maniputetiqg die fhaat service to 
suit their needs. While most priscms restrict die numbers avallabte to inmates 
to call, dw prisonen have myrhd roediods to evade these restrictions. The 
most common method of getting around restrictions to called numbers is for 
die prisoner to call an allowed parQf, such as a spouse or firleDd, who will 
conference die call onto diird and fourth parties to whom die prisoner wishes 
to spesik. 

Anodier common m^hod is for die prisoner to place a collect call to 
a oon^y, such as a telephone oompaiiy, and ask die switchboard operator 
for die accounting department. When d»y are connected, die prisoner tells 
aooounting to switch him back to die switchboard* as she gave him dw wrong 
eitmirion. The aooounting person complies, and now die switchboard operator 
sees an internal extension on her console and diinks die caller is internal to die 
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oompany. The primer aib for an outiiile line, whidi the openior givei 
him, and he places a Um% distance, often internadonal, caU which is bUled tti 
the coni|iiiiy. 

Military peraonnel most often ahiue the calUog cards belonging to the 
paiems of anodier soldier who ibotishly shows smneone hte or her cud, or 
whoptanesacallforsomeonBasaftvor. Thousands of dollars (U.S.) hacve 
been lost in diis type of rituadon, and die carrier hu great difBculqr hoWag 
the parents reaponsible for die charges on their card. The miUtaiy authorities 
aee dils problem as a civUfam matter and often refuse tocoopeiite in pressing 
diarges or recovering losses. For example, one large carrier recently 
attempted, unsicoessfully, to prosecute a number of soldiers ftom a ftxeign 
country who were tminii« on a U.S. base and made U.S. $20,000 in calls on 
a stcrfen card. 

This aipect of die present Invemkm is a ftaud tymm and mediod 
which detects and prevents fraudulent use of die tdephone ^ysMi by 
unaudwrind user. The Inventors have careftdly idendfied die typical 
scenarios where fraud takes place. The present invention d^ects, monitors, 
and prevents such frauds ftom taking place on a real-time basis so diat die 
integrity of die telephone system can be maimainBd. In dils way, vgnificant 
cost savings can be obtuned uMmiely by the carrier using the pmem 
invention. 

This explanation of die fkaud detection and prevendon system AGl 12, 
shown in relation to die odier assoctated systems in Figs. 173, 174 and 175, 
first presents die architecture, data flows, and mediod of opersdon of a 
genendixed version of die fhmd detection and prevention system AGl 12. In 
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Secdoo 7.4 bdow, fifteen ipedfic finuid detection and prewition scenarios 
(fiindkmalities) produced by the firesent invtndon are dlscuned in detail. It 
diould be noted tiiat the present invention is not limited to the specific finud 
scenarios dut are shown, and can be used in odier fravd detection and 
preventioQ applicttioiis. 

In simunaiy, the fimud detection and prevention system A0li2 allows 
for real-time detection and prevention of ftanl It handto bodi calls tint 
suooes^lyoon^lete (go dnoagW, and calls diatftil. The firaud system Is an 
imegiaiBd system that monitors manual opeiakn' conaoles AB132, automated 
VRU consoles ABi34, as weU as BSRVR BA108 and die billing system 
(AQ108). Spedftefiraiid consoles PB106 are provided ID fhuidadministiatori 
as^gned to die task of fhuid detection and prevention. These individuals can 
monitor die opention of any call In the system In real-time and take the 
neoeasaiy actions ffor fraud detection and prevention. Automatic database 
stomge 1^ critical data atwrlaied widi detection and preventkm is pravkled. 
The architecmre of the synem allows fbr specific fraud scenarios to be 
d et e cte d and prevented, as discussed below in detail with reipect to fourteen 
specific identified scenarioa. The piesem invention is robust enough to 
aooommodaie additional fraud scenarios In die future. 

Figs. 173, 174, 17S. 179 and Fig. 176, whidi emprises 177 and 178, 
are die imponam figures fbr refbrenoe in connection witii this explanation of 
a generaliaed version of ftaud detecticm and prevention system A0U2. In 
addition, Ftgs. 179-203 ^how die specifics of die cspability of die presem 
invention to detect and prevent spedfic fraud scenarios discussed below. 

Turning now to Fig. 173, a relatioQship of die fifaud detection and 
prevention system A0112 to odier relevant systems in die present mvention 
is shown. Pig. 173 is a high-level arehitechiral block diagnun showing die 
relationship and interbces of fraud detection and prevention system AG! 12 
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with legiid to the other rtlevutt syttems (onqNinefiis) and ibiwing the 
oommuiiications {nthwayi between the sunt. Referring now tt> Pig. i73> 
ftiud detectton end prevemkMi system AGl 12 OOD^ 
which pertbrms the fraud dMctlon and pievemion, and assocbted ftaud 
consoles PB106 connected by a LAN commankatums link PBlOi. Piaud 
detection and prevention lystem A0112 via fiaud consoles PBIOC provides 
real-time and stored infbnnation to ftaud administralan (not shown). This 
infbrmation alkiws die firsud administnttn 10 iDterM 
and picmtion ^slem AGl 12 on a itaMtne basis so as to efftet die 
action fbr ftaud detection and pievemkxt The ftaud detection and prevention 
system AG112 is connected via LAN AB12I to die odier relevant systems 
(components) In die present Invention. Specifically, fmd deto:tion and 
prevention system AG112 is connected by LAN AB128 to die BSRVR 
BAiOSA. FiauddetectionandpreventionqfStemAOl 12 is connected to die 
nting system LA102 by die communications link provided by LAN ABLU, 
and also by diis onnmumcations link to die validation system AG102. The 
human opeiators can oommuiucate wtdi usen AA106 via mamial openstor 
oonsQleaAB132(seeRg. 17S). In addition, die vinoe reqxmse uniti (VRUs) 
Afil34 which auttrntttically iittenct widi die users AA106 are in 
communication widi die firaud detection and prevention ^stem AGU2 by 
LAN AB128. As shown in Fig. 173, die manual opmtor consoles AB132 
and VRUs AB134 are omnbined and represemed in boot AB108 fox brevlQr. 

In die fraud detection and prevention system shown in Rg. 174, 
specific commands (messages) are provided between specific systems 
(components) diown in Pig. 173. Fig. 174 is a data flow di^grsm showing die 
flow of die importam commands (messages) to and from die fraud detectitm 
and prevention systm AG112 and die odier systems (components) of die 
present invention. 
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Referring now to Hg, 174. the BSRVR BA108A provides FRAUD 
MESSAGES EB324 to a fnud system PB102 of tlie fnuid detection and 
pievemlon tyttem A0112. Piiud mesnges BB324 comprise a itart-ofcall 
message PA182, an intermediale-loQg call message PA180, and an end-ofcall 
message PA178. These tfiree messages, udiscussed below« are used by fraud 
sy«em PB1Q2 to monitor calla dnt do not M and ait oompteted, 

In addition, fiaud system PB1Q2 sends messages to and receives 
messages firom validation system AO102. These messages aie denm. inaied 
questionabte uses PC104. These messages, as discussed bekiw, are used to 
10 ptovide ftar valldstton of calls thiougih the icys»m. 

After a call is tennlnated. fraud system PBia2, as discussed below, 
needs to leodve cost infbnnatioa associated whh diat call. This Information 
is provided by die ndog system iAlQ2. and u called RATED CAIi. DA^^ 
PA172. RATED CAUL DATA PA172 can include die mail cost and die 

IS wholesale cost of dw call diat is oonqrieted and is terminated. Unlike 

trsditional i^siems In ^ich call Wing is performed at some time later in a 
batch process, die avaihibiliiy of real-time rating in die present Invention 
means tiiat an immediate notification is possible when a particutarty expensive 
call has been made. Since diese types of calls are nKHt likely to be made by 

20 hKtos, and since di^ am die most damaging to the carrier, it is extremely 

vahutble to be able to monitor them as th^ occur. 

The pnesem inventkm also keeps track of ftited calls, since failed calls 
provide data about fraudulem patterns diat may he occurring. This 
information is critical for die detection and prevention of fhuid in four spedflc 
25 scenarios, as discussed bdow. The data relatiqg to fiidled calls are provided 

by die manual operator console ABi32 and die VRUs AB134 (which togedier 
comprise GONSOLES MOC/VRU AB108), and are cslled FAILED CALL 
ATTIMPr PC1Q2. 
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Frmud penonnel, alio called fraud admhtomon (not ifaowii), who 
imyvkfethefnialdetBcfonandoontctionint^^ with die gystem usii^ fiaiid 
coiuotes PB106. PiaudconwleiPB106piovkk data visually and aiidi^ 
a monitor, and in hard copy (bm, to die fraud penonneL Piaud penonnel 
provide input data lor interaction widi die fraud syltcm PB102. The 
infonnation oonoemli\g posdiile fraud activity is denominated ALARM 
PA170, and the data providing imeiaction between the fraud peraonael and the 
fraud system PD1Q2 is denominated QUEROB PA168. 

An example aicfaitBcture of die fraud «ystem PB102 is shown in btock 
di^iam finm in Fig, 17S. In summary, die arcUtecture of die fraud qrsiem 
PBI02 is divided into diiee parts: a first part for documeniatioii wbicb 
comprises die reports inodute PA108; a seeotal pari for oomplMd calls wUch 
comprises billed number usage (DNUSAQQ) PA104 and five associated dato 
files (PAllO tt> PA118); and a diird part for caHs diat have ftikd usli« a 
fiuled billiQg number usi^ module PA106 (IWiUSAGQ and four awdaied 
modules (PA120 15 PA126). 

Referring first to die services provided by fraud qrstem PB102, die 
repcms modute PA 108 provides log reports and wpedaH requests, u discussed 
below in Section 1J5. This infbrmttion is provided to a primer PA130 by a 
data padi PA128. Thisdalacanbeprovkled^ponclmuru^Mlby fnuidqf^ 
PBlOl via fraud consok rai06, and also by opentors ai die manual 
coMile AB132. They can alao be preset to run at apecificd iidervab (for 
example, every 3 houn). 

Galb dttt process go diroqgh die system are handled by die billed 
number tts^ module PA104(BNUSAG^). BNUSAGEPAl04intenctawid& 
five modules, PAIlO to PA1I8, as discussed below. Pertisps die most 
inqportam of diese modules is d» short billit« irdbimttion record file nodule 
PAl 10 (labeled SBlRRm^. SBIRHLE module FAl 10 reodves oruncittd 
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billing information record data from the BSRVR BAI08A. Specifically, 
BSRVR BA108A provides START-OF-CALL DATA PA182. 
INTERMEDIATB-LONG CALL DATA PA180, and END4)F-CALL 
DATA PA178. In addition, rating system LA102 provides RATED CALL 
DATA PA172. 

The truncated BIR information is archived in a circular database PA 134 
(the circular aspect is indicated by the asterisk on Fig. 175, and this 
convention is used for die other circular databases shown in PAi). The data 
is provided to the circubu* databases PA134 via a datapath PA132. 

The term "circular/ as used with die database, means that information 
is automatically deleted in the order in which it was put onto the database 
when the database becomes full. In other words, the oldest information in die 
circular database is deleted first. In diis way, the circular database is 
maintenance-free, slnot no deletion is necessary by an operator or an external 
program. A suitable database used for PA134 and the other itatabases shown 
in Fig. i7S is a Sybase model. Sybase is available from Sybase, Inc., 
Emeryville. CA 94606. 

A direshold file, called the billiqg number usage direshold file module 
PAI 14 (BNUTHRS), accesses specific parameten concerning billing numbers 
in die system. These parameters can eidier be global, which means duu diey 
ai^ly to all billing numbers in the system, or can be specific to a billing 
number (called special). These parameters are also called diresholds. They 
are used to determine whether the data on a specific call indicates a possible 
fraud scenario. 

Any particular parameter can be stored in BNUTHRS PAI 14. 
Representative of diese are die following parameters, also called diresholds, 
as follows: 
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• 10 or rooie tnempu on b liqgle billed numbtsr in IS mimttes 

• 2 or more calli per billed number with diffensnt ANI In 5 roimites 

• 2 or more calls per billed mimber with diffensnt NXX in S mimiies 

• 2 or more ctl\tfa billed mimber with dlffepsnt NPA in 60 mimites 
(except fBQgnphical border NPAi) 

• 10 or more curimt active calls whh same billed mmiber 

• coraplded call exceed 60 mimites 

• BSRVR wandi^ on kmg call (every 30 mimtnes) 

• call international 

• call exceeds U.S. SS.OO wholesale ooA 

• caU exceeds U.S. $5.00 leadl cost 

• number of teoriglnatiops exceeds 10 

• 800 POTS changes exceed 3 in 24 houre « with aodOsle alam 

It should be understood diat these are merely nqpremative ami purely 
fw purposes of illustretiaD. The presem invendcm oomemphtes any type of 
parameter/tfucshold. A database PA142 stores and provides ih'apanuneia' or 
thiedtold data via a datapath PA140. In one embodiment, dai8baaePA142 is 
not circular. 

When the present invention determines that a parameter/threshold hu 
beoi exceeded, an atarm is activated or triggered. The information rdadng 
to this alarm is provided by RNUSAGB PA104 to a i^llii« number usuge 
alarms file module PAl 16 (BNUALARMS) for sionge. A circular dMtese 
PA146 is supplied with dus alarm data by a data pathway PA144. Thealarm 
data b provided as alarm data PA170 to die fraud ooosole FB106 via 
BNUSAOE module PA104. Alarms are visual and awfible according to 
ipedfic firequency, time duration, and die like. 

A callfaandle file module PA118 (CHANDFim) is provided widi 
callhandle infonnatton by BNUSAGB PA104. A dtcular datdnae PA150 
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stoitsaiKiprovidesthecaUdataby a data pathway PA 148. DatatMue PA150 
piovides a cross referenoe between the call handle and the billing number used 
in the file. 

The billing number for each call is used by die fraud system PB102 to 
identify the call. This data is provided to a billing number usage file module 
PA112 (BNURLE). PAlt2 creates a BNU record for each billed number. 
A representative BNU record for an ANI showing the data field is found in 
Fraud Fig. 179. It includes, for example, die billing number, tfw billing 
method, current uses, and a list of the last *N' attempts of calls (including 
time, ANI, call information, and the like). If a billed number is not used for 
a particular time period, such as between 30 and 45 days, the billed number 
is deleted from the system so as to reallocate storage space in die database file 
PA138. Database file PA138 receives die data from a data via PA136. This 
database uses a billed number search strategy. 

The fraud system PB1Q2 also monitors and tracks calls that have foiled. 
Failed calls provide critical information concerning fraudulent activities that 
may be occurring. It is tiierefore important tiiat die fraud system PB102 
analyze tiiese failed calls and keep an historical record of tiiem. This altows 
the fraud personnel (not shown) to detect and prevent fraud. Failed calls are 
analyzed by the foiled billing number usage module PA106 (FBNUSAGE). 

With respect to failed calls, perhaps the most important module is the 
short failed billing number file module PA 126 (SFBNFIL), which is provided 
widi a truncated foiled billing number record. Specifically, operator consoles 
AB108 provide foiled call attempt data PA176. The short foiled billing 
number data is stored in and retrieved from a circular database PA 166 via a 
data pathway PA164. A suitable database is Sybase, of Sybase, Inc.. 
Emeryville, CA 94608. 



1462.0010000 



2116462 

-217- 

The pinuneten or thresholds relating lo ftiled billing numbm are 
stored in a fdled bilHi^ number ifarediold module PA122 (FBNTHRS). The 
panunetm or thresholds an stored In and provided from a datriiase PA1S8 
by a datapath PA156. lliese parameters or thresholds are used for the fraud 
5 scenarios based on fldtod calls* 

Whenewr an alarm is triggered based on a paiameter or threshold ftom 
FBNTHRS module PA 122 bdi^euxeded, this alarm inlbrmadon Is provided 
to tfw failed billii^ number alarm module PA120(PBNALARMS). The alarm 
data is stored in and provided by a droular datriMse PA1S4 via adatapidi 
10 PAIS2. In turn, the ahwn data PA170 concerning the Med billing number 

IS supplied by the FBNUSAGE PA106 to die finud console PB106. 

The information relating to each billing number having a ftiled billed 
call is supplied by FBNUSAGB module PA106 to a lUled Ullli« number 
usage file PA124 (FBNUHL). Bach ftiled caO creates a icooid in die 
15 FBNUFIL PA124. A representative BFNU record shovnng Mled call aoempt 

data PA176 Is shown in Fig. 179. Two PBNU recovb are created fat mt 
feiledcall: a first for the originating AN1« and a second for a terminating AN! 
(also called die 'called number*). 

A suitable ftmn for inqilementatioD of finud qfstem PB1Q2 is a 
20 database server. The datalnse server can be on a single platform or nmltiide 

platftmns as required. Any type of operaUng q^sttm can be utilind. A 
sult^le ^ U one usii« UNIX ™ OS/2. 

A data flow for a genenUied fiaud detection and pievention scenario 
in aoooidanoe widi die present invention is rixiwn in bkick dingnm fcmn In 
25 Fig. 176. Fig. 176 comprises a firM Fig. 177 and a second Hg. 178. this 

flow applies to die completed call scenario and to die Med call scenario. 
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Retoring DOW ID Pig. 177. a fint siep ia a wah fbrdacft alep as 
indicaftedbyablockPDKD. The data la Chen meived. as indicated a data 
received block PD104. If the data indicates a call has been terminated, a 
ftooid needs to be written to the SBIRFIL module PAl 10, u indicated by a 

5 8lepPD106. Messi^indicadQg that a call has been completed inchide: (1) 

STARTOFCAIX PA182; (2) PmRMEDUTB-UmG CALL PA180; (3) 
END OP CALL PA178; (4) Med caU data PA172; and, (5) <|iiesdonable uses 
PC104. AhemaiBly, If a call hu fiuled id go ttitouglh, a itoord needs to be 
written to the SPBNPILB module PA126, as indicated by step PD106. A 

10 messv indicatiiv that a caU has fkiled is FAILSD CALL ATTEMPT 

PA176. 

The shortened billiog Infiumadon record (SBIR) is dien stored in 
SBIRPILE PAl la The shortened ftiled billing number record (SFBN) is then 
stoied in the SPBNPIU module PA126. This storage is indicatBd liy a step 
15 PDlOg. The usage ream! ten needs to be ddier or obtained and updated if 

it is in existence, as indicatBd by a step PDUO. The SBIR is used to obnun 
Ite BNU, and te SPBN U used to obtain the PBNU. 

Widi respect to a call that has been oomi^elBd, the billing number 
us^ (BNU) record for diat number must be obttined from BNUFILB PAl 12, 
20 as indicated by a step PD112. Sindlarty. if a call fiyis to go diroug^, the 

ftiled billii^ number usage (PBNU) record needs to be retrieved from die 
FBNUnLE module PAI24. as Indicated by step P0112. As an aside, Pkaud 
Pig. 179diowsrepreseniadveenmplesofBNU record (for a complex 
and a PBNU reoocd (for a Med call). 

25 The data flow diagram from Pig. 177 extends to Pig. 178, as Indicated 

by the reference dide PD114. Referring now to Pig. 178, te BNU record 
fbracompleted call and te PBNU record for a biled call needs lobe updued 
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in the lapecdve &NUP|LB module PA112orthe BRNUFIUB module Iv J 
as indicited by t block PEKB. 

With n-^ect to a completed call, the paiametei or ducihsli 
information for the billed nuniber needs to be checked to determine if a Pnui 
soemtfk) has been detected and an associaied fraud scenario alarm needs lo bt 
triggered. In this icgaid, the threshold reconi for the billed number * ft the 
completed call is obtidned from die BNUTHRS module PA114, as inl catel 
by a step PB104. Alternatively, for a failed call, te direshoid ncocd di& 
failed billed number is obtained fiom die FBNTHRS module PA133:, is 
indicated by step rei04. 

The next step is to determine whether a fraud scenario has ti»es 
detected (which is also refiened to as triggering an alarm). With lespect t3 i 
c o mp l eted call, die parunelen (Khicshohta) for die billed number obtsiiei 
fhrni the BNUTHRS module PAl 14 are conqiared to the oomsspondiqg dati 
frmn the BNU record in order to determme whedier the fraud scenario (alarm) 
has been found. If no alann is found, die data flow returns to wait for dati 
step roi02, as indicated by die loop pathway PDl 18. Alternately, if an alam 
has been ficwnd (ftaud scenario delected), as Indicated by die YES on data pati^ 
PD108, die afamn (fraud scenario) tfaua needs to be saved in the billing nuniber 
usage fik in dw BNUALARMS module PAl 16, as iml'icated by a step PDU 
Thereafter, an alarm indicator detection of die fiaud scenario is sent to die 
fraud consoles PB106 indicatiog the alarm condition widi respect to die 
completed call, as indicated by a step l*D112. Thereafler, the generalized 
fraud d^ectlon and prevention scenario returns to wait far data step PDIQQ. 

Similariy, for a ftdled call, if fraud scenario (alarm) is determined to 
not have occurred, the dam flow returns to wait for data step PD1Q2. If a 
fraud scenario (alarm) has been determined to have occurred, however, diis 
is indicaied by die YES condition on dara padi PD108. The daecdon of die 
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fnud nenark) is peifonned 

ftitod mmdw otelned from ttie PBNTHRS module PA122 with the 
oorieapoMfingdil&firomthePBNUieooidfiirtbe^ Thealtnn 
Is saved in the FBNALARMS module PA120, as Indicaied by step PDilO. 
In action, an alam lidkatf Qg dettctkm of die 

to die fiaud console PD106. indicating die condition of the fiuM call, as 
shown by itsp PD112. ThenafiBT, die genetaiiaed finuid dtiecdon and 
pievention aoenario, via padiway PDl 1 8, waits for new data, as indicated by 
Stop PDiCB. 

The system and mediod of dte pmem invendon using the fh^ 
raiOZ and die fnuid consoles PB106 In connecdon whb die odier systems of 
die present invendon as shown In Fig. 175, 173, and 174 allow die firaud 
admininiator (not shown) to detect mMct pievem a significant number of 
specific Ikaud scenarios which have been Idendfled 1^ die inventon. Rgs. 
180-195 show die fraud detecdcm and pievendoa capability of die present 
invendon against tl» specific firiud scenarios. 

Refierring now to Figs. 180-195. There are fifteen different finuid 
detecdon and/or prevendon scenarios in accordance widi die present invention 
which are described below. At a high level diey all udliae the arehitecmre, 
niediod of operadon, and data flow of dK fiaud system PB102 and fiaud 
consoles PB106 described above in Secdon 7.3. These are representative of 
die present Invention and should not be viewed u beiiv die only detection and 
prevention scenarios diat can be provided. 

The fiaud detection and/or prevention capability of die present 
invention can provide real-time alarms dud can be groii^ into two 
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cattgmiei: (1) thoK alanns which occur widi a ftiied call attempt; and (2) 
thoae alaimt which occur with a completed call. With reject to oomplelBd 
calli. the pftaem invention can piovide cenain alamii at the h^nnii^ (itan) 
of the compSeied call, after the completed call hu been in exiatenoe for a 
specified amount of time, and after the bilHog data hat been detmined for 
the compleced call that Is terminated. It should be imdentood that a qiecific 
fiufedcdl or oonipleted call can cause one or fttoceatarnu to occur. Itshouid 
also be understood that the piesem inventsoo can lie co p f i g uff B d so that the 
alarms can be customised at any level of gianulafit> ton specific carrier, to 
specific end user, and all the way down lo a panicubr Inlling number or 
ori^natii9 ANI or called number, etc. This sbUity to oonfiguie the fiaud 
system PB102 u well u real-time fraud detecdon imd/or p itventkm greatly 
enhances die capability of the piesem invemion to detect and/or pmM fifaod. 

7M FMQM 

Set forth below are descriptions fat fiour fiaud detection and/or 
pievention sceittiios In oomiecdoo with tte piesem iovemion w^ 
abiledcall. A ftiled call is one where the validtficin system AGi02pimnts 
a can fiPom beii« completed because it fidls one or ^.m puameters. As 
discussed in section 7.4 J, diese iUled pammeiBii, fior enmirie, 
a blocked orfglnsdng ANI, a btodced temunadnis AN!, a bftodoed billing 
mmber, twoorrooresimultaDBOuscallsonadcbitcaid where the second call 
is blodoed und) die first call b comptod (see siicdon 7.4.2.S), a blocked 
NPA, a blocfcod NPA/NXX, denied validation, invalid fiormat of a card, 
invalid cdlii« areas, or a customer fidU to oompkte dkliQg all die necessary 
digits and disconnects, and die Hke. 

ChK or more of the four fraud detection and/(v prevention soenarm 
fbrdi bdow in aoooidanoe widi dte prcaem invention can occur on a single 
fiuled call. The Mled call attempt scenario of Section 7.4.1.1 will always 
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occur fwa^yfidM call. HoweverJnadditioa» the (ailed call can also result 
in one or moie of the other three scenarios occurring. In some extreme 
situations, a WIed call can tesuh in all of the fcmr scenarios occurriiig. 

These fiwr scenarios are particuhuty effective for detecting the 
acti^ties of a hadw or phone phreak v/bo is tiying to gain unauthorised 
mess to the ide^ume system to commit ftaud. The detection and/or 
prevcndon of fkaud far each ftibd call providea real-time information to die 
fraud penonnel (admhiistnm) on the ftaud consoMs) rai06 so tint she can 
take appropriate action to protect tiie tetopfaone system. Her actions can stop 
additional ftmdfkom occurring because tiie attack on tiietdcphoneoratem can 
be immediately dealt witii so tint additional precautions can be taken. Failed 
cdls provide die firaud administrator widi extremely valuable information 
concerning attempted Aaudulem activities dot have not yet caused economic 
harm to die tdepbone system , but if not known and not acted on can and often 
will resuh in great financial loss after die hadeer or phone phreak has achieved 
aocen into the telephone system. 

7.4LI.I FgikdCuUAttaipi 

Hie FASLSD CALL ATTlMPr MESSAGE PA176 is provkled by 
die operator consoles ABlOg to die fraud system PB1Q2, as shown in Pig. 
175. Referrirv now to Fig. 179, Pig. 180, and Pig. 181. die fidled call 
attempi scenario is discussed. Rg. 179 shows a RpteaemativePBNU record, 
whfeh is stored hi die PBNUnLB PAI24. Bach Ikiled call results in a PBNU 
record being created, or updated if already in existence, for that foiled call. 

Fig. 180 shows a high level block diagram of the four fraud soenartos 
diat can be detected and/or prevented in acc o rdance widi die preaem invention 
for a foiled call. Pig. 181 breaks out die specific foiled call attempt scenario 
of Ftg. 180. 
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The FAILED CALL ATTEMPT MESSAGE PA176 is received from 
the consoles AB108 by fraud system PB102. The receipt of the FAIL£D 
CALL ATTEMPT MESSAGE PA176 is indicated by a PP1Q2, as shown in 
Fig. 180 and Fig. 181. The SFBNFILE PA126 stores the failed call attempt 
message PA176. The SFBN is used to obtain the FBNU record for the failed 
calK and to update it The failed call attempt parameters (thresholds) stored 
in the FBNTHRS module PA122 are obtained, as indicated by a box PP104. 
The FBNU data for die ^led call from the FBNURLE PA124 is conqiared 
with the thresholds (parameters) from FBNTHRS PA122 in a decision box 
PP106 to determine if ont or more of the diresholds (parameters) have been 
exceeded. If no threshold has been exceeded, dw foiled call attenq>ts scenario 
has not been detected as indicated by a NO flow line PP108. Thereafter as 
indicated by a DONE block PPl 10, the FBNU record for the originating ANi 
is updated and the FBNU record for die terminating ANI (also referred to as 
the called number in Fig. 180) js updated for the ftiled call. The records of 
the last 'N' attempts are updated in these two FBNU records in order to reflea 
the failed call. 

In contrast, if one or more of the diresholds has been exceeded, as 
determined by decision block PP106, the failed call attempt scenario proceeds 
to a YES flow line PPl 12. A foiled call attempt alarm is then generated, as 
indicated by a block PPl 14. The foiled call attempt alarm is provided to two 
parts of the present invention. The first part is die foiled fraud attempt alarm 
provided to fraud console(s) PB106, as indicated by an alarm line PA170. In 
addition, the alarm data is stored in the FBNALARMS module PA 120, so that 
the failed call attempt alarm information can later be retrieved by fraud 
personnel. This alarm information is available for detection and/or fraud 
prevention activities and archival purposes. Afler these two activities have 
been completed, dw failed call attempt scenario proceeds to a DONE block 
labeled PPl 16. This completes the foiled call attempt scenario FRAUD500. 
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7.4LI.2 Hoi OrigbmHng ANi 

The fhuid detection and/or preventkm 
piemt inventkm te a hot origiiittli« ANI it now described. At discussed 
daewbere, die orlglnatiiV ANI is a ten-digit miinber indicating die number 
from where die call OTiginaM (it does not indude die coamiyoote "HOT 
means dial die immber has been pievkMslykkmifM as bdog CM 
ortDwhidkftaudisoocuning. ReHnrenoe b made to Fig. ISOandRg. 182. 
Pig. 182 diows die steps of die scenario fdrbodi a hot origlnadiig ANI and 
die steps of die scenario for a hot termlnadng ANI (also referred to as a hot 
tenninadog number). 

Tliehotoriginadng AN! scenario Is typically perfimed after die ftiled 
call attempt scenario Is perftmed, u discussed above In Secdon 7.4.1.1. 

Referring now id Fig. 173, Fig. 179, Fig. 180 and Fig. 182, die felled 
call attempt message PA176 Is received by fnud ^stem rai02 fnm consoles 
AB108, as indicated by bkick PP120. Fsiled call attempt message PA176 Is 
stored in SFBNFILE PA126. The hot originating ANI parameten 
(dinsholds), u indicated by a block P120, uring die SFBN are obtained ftom 
FBNTHURS PA122. These panuneters indicate whedier die HOT FLAG in 
die FBNUPILE PA124 need to be checked. Next, in decision block PPI06, 
die HOT FLAG flekl in die FBNU record Is checked to determine whedier die 
origtnadi« ANI <a die failed call is hot 

If die felled call originating ANI is determined by decision bkick 
PPI06 not to be hot, die hot originating ANI f^ scenario proceeds via a 
NO flow line PPIOZ to DONE bkick PPI 10. Tlie FBNU reooid fbr die feiled 
call originadi^ ANI is qidand to reffect diis last call in die FBNU record 
PO402. Thus, it can be seen diat all feiled calls are exanuned by dris finud 
scenario to determine if die felled call was from a hot originating ANI. 
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Altenwidy, If dedikw Uock PP106 dmasAm ibiit (be qdl ii fiooi • 
hot origiDadng ANl, the ftmid toenario proceeds atom * Une PPI12. 
ThiilndlcatetlliatihehotoriginUiqg ANlioe^ Ahot 
originadm ANI alann is genemed by a P114 block. TWo icdvitiei dieii 
occur. Fim, the hoc originadiv ANI mesagePAlTOb provided to the fti^ 
adinliditnaoiiantetaiidcmttole(i)PB106. In addition, teraNALARMS 
file PA120 if updated to include fhia alann inftmnatioo fiv tubaeqnait ine, aa 
indicaied by die iX>NE btodc PP116. In this way. a lepanie alam ia 
provided to the fiaud adminiitntt^ for a MIed adl whkh ate 
a hot originadiv ANl. Thus, the ftaudadministiator can determine not only 
thatafidledcall occurred, but tfttt dw ftiled call came from a hot originaiqg 
ANI. The fnuid administnlor can act aooonBogiy. 

7.4.U Hm IVrmlMtfv ANi 

All fidlcd calli art also cfaedmd to determine whedier diey aie from a 
hot terminatiiig ANI or number. The flow used for determining dus fraud 
scenario and for taldm die i^iprapriate M4ion is die same dM 
hot origimdiQ ANI discussed above in Section 7.3.1.2. For pmposes of 
brevity, mdy die differences between die hot originatiiv ANI and die hot 
lermlnadng ANI are discussed. 

Fint, die order in which die hot originating ANI and die hot 
tenninatimg ANI scenarios are perftmied does not maoer in a ccor da nce widi 
die ptsem invention. Th^canbedonesequentially inddiermder, ordooe 
in parallel. The hot tenninatii^ ANI paiameteis, as inficsled by a btock 
hdidedFRAUDS20, are obtained fhmiiWninL^ In addition. If die 
teminatiiv ANI is detmnincd not to be hot (called 'ccdd*), die FBNU record 
fiordieienninatii^ ANI Is iqidated to reflect die foiled call as discussed sbove 
in die FBNUHLE file PAI22. Thte updating is indicated by IMNE block 
PPllO. 
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Slmilariy, if the terminating ANl is detemiiied to be hot by decision 
block PP106, two activities occur. Hret, a hot term! rating ANl alam PA 170 
is provided to the fraud administrator on the fraud (xmspie PB106. Second, 
the fisud atann data for die hot terminating ANl is stored in tfte 
FBN ALARMS file PA120. 

In this way. a sepamte alarm is provided to the fraud administrator 
indicating that dw ftiled call has been directed to a hot terminating ANl. 
Thus, it can be iw^ciaiBd diat a Uled call can also rewlt in an alarm(s) 
indicad^g diat it is from a hot orig^nadng ANl and/or is directed to a hoc 
tenninadng ANl. This fhuid information provides die fhuid administrator witti 
addltbnal data so as to make appropriate acdtm to prevent fraud occurring 
widiln die leieoommunication syttun. 

iiltkVmg$OiiBmgNmnb$r 

This fiiud scenario in accordance widi die presem invendon provides 
die capability of d^ecdng and/or prevendqg a number of calls from an 
originadng ANl and/or to a lerminadng ANl which exceeds a apedfic number 
widi a specific time. This fiaud scenario ^picaily oocun where a hacker is 
trying to discover die proper PIN fen* a billii^ nuRiber so as to gahi access to 
dist billing number. Presendy, hadcers use very sophisdcaled techniques to 
determhie die proper PIN for a billing number by using, for example, 
oompuiN programs that automatically generate possible PINs in niooesrive 
calls so diat widiin a diort period of time die proper PIN is uncovered. The 
pieaent invendon can detect and/or pievem this fraud scenario ftoro occurring 
by detecting in real time when a particular number of foiled calls have 
occurred for a designated originating ANl or a terminating ANl widUn a 
predefined period of time. 
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..fe^ncctoRg.. 175. F.g. 179. Rg. ^^^^^ 
diagram of the representative steps of this fimd namrio. 

it should be underatood that the «««uio de«ribed below appUe, both 
to an originting ANI airf to a termi«d„g ANI (.!« .efcned to as . cdled 
aomber). Ether or both the origi^fi^ ^Ni and the tenninating ANI of a 
fiuled call am be evaluated to determine whether the abrnn threshold ha. been 
exceeded. " »hould be understood ,h« the present invemion contemplates 
checking eid«r or both the originating ANI M the tenninating ANI of a 
Mled call. 



Referring now to the figure,, iht FAILED CALL ATTENOT 
MESSAGE PA176 is received by Ae ft^ ^ p^,^ ^ 

AB108 as indicated by block PP102. Rg. 183 i, a combined figure showing 

the flow of tf» fhtud scenario for the originating ANI and the flow of the 

fraud scenario for the terminadng ANI. I, should be understood that d« steps 

set forth in Fig. 183 are imptemented »njint»i» • • ami j 
» K »ica separately for an onginating ANI and 

a lerininatiQg ANI. 

The FAILF.D CALL ATTEMpr MESSAGE PA176 is stored in the 
SFBNFILB PAI26. Tht parameter, or AreshoW, indkuing the high usage 
value for the originatiitg ANI are then obtained fnm the FBNTORS PA122. 
as indicated by a block PP124. •hereafter, the FBNU recoid for the 
originating ANI is obtained from PBNUFILE PAI24. The last 'N' mimber 
of failed calls for the originating ANI. as stored in this recoid of PP4a2 file, 
are reviewed to determine the number that have occuntd within a ' V period 
oftime.asspecifiedbythepanme,«,ofstepPPl24. Tlie review of the last 
•N- calls for the originating ANI are i«Hcated by a block PP402. as shown in 
Rg. 183. If the number of calls wifti„ tf« specified time frame is less dun 
the value direshold for that originating ANI. die high usage fraud scenario has 
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not been delected, and the flow prooeedi atom line PPI08 to DONB block 
PPllO. ThteMindkateftthatnoeicetsivehighuKof theorlglndo^ 
of tbe fiuled call hai oocuned. 

However, if the minter of &iled calls Aom die originadng ANI within 
5 the ipedfied time fnune his been equal to or has exceeded the threshold, 

dediion block m06 drtects die high usage ANI finaud Tliefkiw 
proceeds akH^ die YES UnBPPll2* A U|b us^ orlgbiadng ANI alarm is 
generated by atannbtodcPPlU. Two acdvUes dien occur. First, die high 
usage originadi« ANI abra PA170 is pravhM to die fkaud oon80le( 
10 so diat die fraud adndidstrator can take ap pro pihue actkm. In addhioo, die 

FWALARMS PA120 is piovided widi diis atarm tnfbrmatkm for stmageso 
that it can be obtained for later analysis and di^pU^. 

Once diese two acdvides have been completed, diia fiwud scenario 
proceeds to die DONB step tadieled PPIM. 

IS As stated shove, dieevaluationofdietBrminadng ANIforafiuledcail 

is done in simifav fiuhlon tt> determine tf any thieshbld parameter for that 
teraiinadiig ANI has been exceeded widdn die specified 'Y* period of time. 
The present invendmi can check bodi dieoriginadi« ANI and die terminating 
ANI fbr diese high usage ooadldons, or can check only one depending on how 

20 die fraxKi system PB102 is configured. 

In diis wsy, the fraud administntor can use diis infiMination about 
foiled calls dm are repeatedly being made fnm or to a particular ANI ao as 
to detect die hackii^ which typically occurs, fbr example, when a hacker is 
tryii^tt) determine die PIN fior a btlliognundier. This capability alkiws die 
25 present invendon to be protected against typical hacking scenarios dial 

pieaemiy occur. 
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AsdiicusKd ibove in section? J J, ihe pieiem 
all ftdled calls to detennine whether a fiftud loeflario hu been delected and/or 
needitDbep i c vem ed. loadditlmi. the pieienclnvattioiu as described in lids 
aectim, euminet all oompleied calii (calli thai go fhrouglO to detennine 
whether each <rf dieae calU aattefles aqy of the fmud deiecikm aad/or 
pfevotfionacenarioe that have been gittfimtred fa the fhu^ 
co nn ecti on with die qrpe of call, wfaeie die call ori^nttei ftom and goes to, 
9pe of Irillii^, dte COM of diecail, die dme ditntiQa of the call, and die like. 
These various panmeteis of die c om ptete d call aie evdioaed in a oooni a nee 
widi bow die fraud ^yitemPBlOZ is customtnd so diat die present invoidon 
can produce an improved abili^ to detect andAv prevent fnuduleitt acdvidei 
reladogtocompleted calls. ThislsalldooeonaRal-tiniebaris. wtdchiesohs 
in cost savings because fraud detection and/or prevention can be aooonptiafaed 
much sooner dmn would be die case if it was mdy done after die completBd 
call was terminated and had been Mlled. 

It should be understood dtst die con^ileted call fiaud scenarios 
described below are not all required in scconianoe widi die fraud system 
PBIQ2 of die present Invemion. In tet. die firiud system PBIOZ can provide 
as fiew as one of diese ftaud scenarios and still fnoduoe significant fxand 
savii^. Moreover, die fhuid system PB202 can be customind to a 
gmmitarity'of a particular billing number, originating ANl, or tenninadng 
Am, etc In diis way, enhanced finud detection and/or prevention can be 
achieved 1^ die present invention. 

The fnuid detection antVor prevention scenarios of die presem in veni^ 
for oon^letBd calls occur in real time. The poim in time during completed 
call when a paiticutar fiaud scenario occurs can be broloen down imo three 
categoto h) accordance widi die presntt invention. The first category of 
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ffiuid toenariot il mm which occur when the call is oompteced. Pnud 
aomita ouainpd hi Scctkm 7.4.2.1 id 7.4.2.8 &II within Ais itan of call 
thne ffame caiegoiy. The second gn>up of ftaud scenarios oocun after the 
convtetedcdlhasbeenineidsienoefoapndeiennlnedaimMimofrim^ The 
ftand aomnrio In Section 7.4.2.9 Mb within ihia aecond dme frame categmy. 
lite tidni dine finm categoiy is after die call has been tannine 
infbnnatian has been delenniiKd for diatterminatBd call. This firaud scenario 
is set fisrth in Section 7.4.2. la 

Thus, h can be seen dial the preseminvendoopnivides real dm fraud 
detficdm and/or prevcndon capability for ooraptoted calls. The present 
invemion no looter nqidres die teleoommunicationi carrier tt> wait undl after 
die oompletBd call is over or undl after bWiog information hu become 
avaihdite in order fbr fhnid detecdon and/or inevendon to lake pl^ This 
improves coat savinp associated widi ftaud detecdtm and/or prevention of 
completed calls. 

Refbrriqg nowtoFig. 185, a blodc dfaignun of die steps in acooidanoe 
wldi die pvesem Invention for determining wh^r an originating ANI is hot 
fior a oomplMd call Is diown. It diould be noted dat die block diagram set 
fbidi in Fig. 185 is equally applicable for die hot tenninadng ANI fhuid 
scenario discussed below in Section 7.4.2.2. 

Referring now to Ftgs. 175, Fig. 179, and Fig. 185. a START OF 
CALL l^ffiSSAGE PA 1 82 is provided by die BSR VR BA108A lo die fraud 
system PB102. This indicaiBsdttt die call has been completed and has started. 
The start of call information PA182 is supplied lo die SBIRFILB PAl 10 by 
die BNUSAGE PA1(M. 
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The START OF CAIX MISSAGB PA182, u indiattd by a 1^ 
PQlCn, begins the hot ariginatii% ANI loenirio. Neit, the thmhoUi hi 
BNUTHRS PA114 aie checked, as indicalDd by a bOK PQ1(M. id dctenmae 
if a hot check of the origlnatiflg ANI should be made. If no hoc check Is 
indicated by the BNUTHRS PAI14. ten the hot origintii« ANI firaud 
scenario te not implemoued, as indicated by the DONB hkxk PQ106. Note 
that for each originatii^ ANI, a hot check can be costomiaed by the fraud 
system PB1Q2 the present inventkm. Thisequatty a|ifriiestt>eiditetmioBtiiig 
ANI. 

If BNUTHRS PA114 indicates that a hot check la to be perfonned. as 
iodkaoed by the YES <m a flow line PQI08, die BNU recoid P04^ 
179) for die orlglnadng ANI stored in die BNUFILE PA112 is diedmd 
Oooked up), as hidicatBd by a block PQHO. If no BNU recoid FRAUD450 
is found for die originatb« ANI, u indicated 1^ a Ihie PQ1I2, die hoc 
originatiiig ANI fiaiid scenario is completed, as hidicaiBd by bkick PQI06. 
As an askle, a new BNU moid is created for diis orfginatmg ANI oonpleted 
call hi aococdanoe widi die creatioo of Ae BNU recoid as described 
elsewhere. 

If a BNU recoid PO4S0 for the <»iginadi« ANI is found in BNUHLE 
PA112, u indkatad by a line PQ114, die BNU reoonts POiSO are diecked 
to determine if die hot field is set to M%whkhindlcalesdaa die original 
ANI hu been designated as hot by die fraud admndstnior. If diehocfiehl is 
set to *0", die originadng ANI is designated ooM, as InBcated by a ffow line 
PQ116. The hoc originatiiv ANI fraud scenario moves 10 bkickPQlW^ 
die BNU leooni PO450 for die originadii ANI Is updated to reflect die 
ccmipleted call in fleM P04S2. 

If die hot field is found to oomain a "T, as indicated by a flow line 
PQl 18, an alarm is generated, as shown 1^ a btock PQ120, indicating diat a 
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hot origiiatlng ANI fnuid aoenario has been detected. Two acdvitia dien 
occur. Finl«diehotorigiiiatkm ANIalannPAlTOispTQvi^ 
admiiditiitorbyfnudoon8ole(4PB106. In addition, die ahm data is stored 
in die BNUALAM4SPAU6 for subsequent use and analysis. Thereafter, die 
hot origlnadi^ ANI fiaud scenario is completed, u Indicated by blodc PQ122. 

In diis way. dtt presem Invemto can detect when a ooin|>leted call has 
originated from a hot originadng A^^ at die beginning of die call after it hu 
been completed but before die call is over. This allows die fraud 
administrator to monitar die acdvl^ of die hot orlginatii^ ANI. in diis way. 
fraud detection and/or prevention acdvides can take place by the fraud 
admiiustrator In con n ec tio n with completed calls. 

7.4.2.2 Hoi TumbmUtit ANt 

The description set fordi ^love In Secdon 7.4.2. 1 is applicable here. 
The only nu^ difference between die two Is diat a hot terminating AMI is 
checked by this fmud somurio, as opposed to die hot originating ANI diat is 
diecfced in die fhuid scenario set fahh in 7.4.2.1. 

The BNUTHRS PAIU indicates whedier a hot check Is to be 
periionned by die terminatiqg ANI. In addition, die BNU record for die 
tenninatii« ANI Is updsted to reflect die completed call. 

Under this scenario, die fraud administnitor can ddect at die beginning 
of a completed call duu die call has been made to a hot terminating ANI so 
diat sultsble fraud detection and/or prevention can cake place before die 
completed call is completfid. In tills way, significant avings can occur. 
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This fraud aoenario in aooordanoe with the presem invcndon oocun 
when'N* callsareoomplettdlbraptrticutorbllUngm^^ 
of time. Thii potential fraud ooodidon needi to be d etect ed and/or pteveuied 
by the piewnt invention ao that a nuiriier of caib on a particular billing 
number do not exceed a Kt amount 'N' widiout the fraud administtatorbeiqg 
made awaic ai the situation. This high usi^ can ehher indicate that die 
audwriaed customen are utilizing die bilUog number in a gitner dan normal 
d^ree, or diat fhuidulem activity may be occurring and needs to be supped. 

Reference is now made to Pig. 175. Pig. 179. and Pig. 186. Fig. 186 
shows a blodt diagram of die stepa diat take place in diis fraud detection 
and/or prevention scenario in aocofdanoewtdi die present invention. Itshould 
also be noted daa Pig. 186 is equally applicable for die steps whidi occur in 
die high 800 usage fraud scenario described below in Secdoo 7.4 

The Stan up call message PA182 is provided by die BSRVR BA108A 
via BNUSAGE PA104 to die SBIRHLE PAl 10. as indicated by blocic PQ102. 
Hie high usage panuneten (direshold^ for die particular blllfaiig number are 
obt^ned from BNUTHRS PA114, as indicated by a bkxk PRIOZ. These 
usage parameters indicate die number of completed calla *r dat can occur 
wtdiin a period of time *Y\ Atiy calls equal to or diove diat specified 
number 'Z* indicate dat die high usage direshold or oonthtion has beoi met 

The BNU record P04SO for die particular billing number, which is 
stored in BNUPILE PA1I2, Is dien checked. Specifically, die last 'N* caHs 
found in fiekl P04S2 are checked to deternune die immber 'A' dat have 
occurred widiin die time period 'YV This checkit« of field P04S2 of BND 
record PO4S0 for die particular billing nundier in order to determine die 
number 'A' of completed calls is indicated by a block PRI04. 
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If the nunter 'A' of calls that have oocuncd within the time period 'Y* 
is less than the threshold value 'Z* provided by step PRia2 for the partiimlar 
billing number* then this fraud aoenario detcmiaea that the high uage 
condition has not occuned, u indicated by the NO flow line PRIM. The 
fiaud scenario then updates the BNU tecoid file P04SO to indicate ftis 
completed call. This is indictted by iX>NB block PRUO. 

Altemtfely, if the number of calls *A' In time period *Y' Is equal to or 
greater dmn the threshold value a dedsonal blod^ PR106 indicates that Che 
threshold has been equalled or exceeded, as indicated by die YES flow line 
PR112. 

Thmafter, the partioular billiog mimiber is examined to determine if 
it is an NPA 800 number. Hiis is indicated by a decbion block PRl 14. If 
dedskm block PRIU determines that the billing numb^ Is not an NPA MX) 
number, a high usage billing number ahurm is genenled, u indicated by a 
bk)cfcPR116. Two Mtivides then occur. The first activity is that die HKm 
USAGE BILLING NUMBER ALARM PA170 b provided to die fhuid 
administmtor on die fraud oon8ole(s) PB106. In this way, die fraud 
admiuistraior knows diat die high usage billing number omKfltkHi has occurred 
at the beginning of die completed call (and not after die call is terminated). 
This altows the billing administrator to take aniropriate action. In addithm, 
a high usage billing nuihber afam data is stored in die BNUALARM S PAl 16 
for biter use and analyns. This fraud scenario dien proceeds to the DONE 
block PR118, which indicates diat die scenario has been completed. 

Thus, it can be seen tint in diis scenario a high us«ge billing number 
condidon can be detected at die beginning of die call, and not afte die call is 
terminated isc after billing inftmnatitm is provided. In diis way, die fraud 
admiiustrator can take appropriate acdon u> dMct and/or prevem fraud. 



1462.0010000 



2116467 



-235 - 

7.4.2.4 800 Calk WW High Usage 

The fraud scenario in aooordanoe with the present invention that 
determines if 800 usage parameters are exceeded is similar to diat described 
above in Section 7.4.2.3 and discussed in connection with Figs. 175, Fig. 179 
and Fig. 186. Only the differences between these two fraud scenarios are 
discussed. 

As shown in the block labeled PR102. the high 800 usage parameters 
'Z' are obtained from the BNUTHRS PAli4. 

Similariy, if the number of 800 usage completed calls is equal to 
or exceeds dte threshold *Z\ as indicated by decision block PR106, then the 
decision block PRIM determines if the billing number is a NPA800. If this 
NPA800 condition is determined by declsiotial block PR114, as indicated by 
YES flow line PR120« a high 800 nuniber usage alarm is generued, as 
indicated by a block PR 122. Two activities dwn take ph»e. One is the high 
800 number usage alarm PA170 is provided to the fraud administrator on the 
fraud console(s) PB106. This allows the fraud adminismoor to take 
appropriate action to detect and/or prevent the fraud before the completed 800 
call is over. The other activity is that die high 800 number usage alarm data 
is stored in the BNUALARMS PAn6. This allows this data to be 
subsequently used and analyzed by the fraud administrator. 

Thereafter, the high 800 usage fraud scenario is completed, as 
indicated by the DONE box PRUg. 

7.4.2.5 Simultaneous Caik on a BUUng Number 

This fraud scenario in accordance with die present invendon detects 
and/or prevents the condition where there are two or more active calls on a 
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ptfticular billiog number. Thta ftuid aoenuio lypiadly oocon when a bUliqg 
iHimber (with its anociated aooeas PIN) it QtMained by in untudioriied user 
and then used simultaneously by two or more urauttboriad users to nuke 
overlapping Gn time) uniutboriaed calls. The stolen billing number Is ofken 
sokl ID many uniuihorized users who typlcslly use it sa extensively as posstt^ 
widdn a short time period so that the ftaud.mne it is delected. isdifRcult, if 
not impossible, to crimtnalty prosecute. This simultaneous calls oo a bllliqg 
number fraud scenario in aoooidanoe with the presHtt Invoition det^ 
prevents this from taidng place. 

Refeniiv now to Fig. 187. a blodc diagram of die steps of diis fraud 
soottiio in aooofdance with die present invention are shown. References are 
also made lo Fig. 179 and to Pig. ITS. 

Referring now to Fig. 187, die start of adi message PA182, as 
indicated by block PQIOZ, isrecdved from BSRVR &A108 by fraud system 
PBKXZ. The start of call message PA182 is used to retrieve die BNU record 
P04SO far the billing number. Reierring to Rg. 179, die BNU record P04SO 
includes a field called 'current uses*, which is tabeled P04S4. This 'cunem 
uses* field P(MS4 indicates whedier diere is a oompietBd call in progress, 
whidi means dial diere is a call using die billing number which has been 
completed but Is not yet terminated. Any type of indicator can be used to 
show die state where diere is a completed call in progress. For example, a 
*zBro* can show dut diere is no call in progms.anda*r can show dial there 
is a call in progress. This 'curreiU uses* P0454 infwmadon is obtained from 
dieBNUrecord P(M50 found in BNU file PAl 12. This is indicaiBd by a step 
PR202. 

A decision step PR204 determines if die vahie of die 'current uses' 
from field P0454 is equal to or exceeds a value direshold obttined ftom 
BNUTHRS PAl 14. The value direshold qwdfles how many completed calls 
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onatii^MlliiigminibercBnbeinpfogieiiatoiietim It iliould be noiBd 
duu the present invention can be configured ao tint the delected simultaneous 
calls onadogte billing number condition can occur with one <Nr more calls in 
progress. In other words, the pttsem invention is not limited 10 deteccioa of 
the sUuatkm where only one call is in progress. Two or more calls cin be 
spedfbd in the threshed as being required to be in piqgrea for this fnuid 
scenario to be tteteded. 

If decision block PR204 defiermiaes dutt die dirediokl has not been 
equaled or exceeded, it|m)ceedsakmgaNOflowlii»PR206(oDONEblock 
PQ106. This indicates dat the scenario of sinmhaneous calls on a sh^ 
l^liiQ n u mb e r has not been detected. 

Incomiast, if decision block PR206 determines diat die 'correntinBS' 
value (dud is, die nundicr of timultaneous cail^ is equal to or exceeds die 
dueshoM vahie, it proceeds akmg a YES flow Hne PR208. A dmuhanoous 
calls on a siq^ billing nondier alam is dien genetated, as indicated by a 
blockPR2IO. Two acdvides dim take plaoe. Rrst, die simuhaneous calls on 
a billing number fnud scenario atavm PA170 is presented to the fraud 
administrator on die fraud oon8ole(s) PB106. In addtkm, die slmuhaneotts 
calU on a Uning nundier ahum dsta u stored in die BNUALARMS PAl 16 file 
for later use and analysis. Thereafter, the flow pioceeds to a DONE box 
PQ106. 

In diis way, diis fraud scenario can delect and/or prevent a fraud 
scenario where diere are dmultaneous calls on a sif^ bill]i« nnndier. Tins 
alkiwa dtt fraud adnumstnte to take neoeassiy action agiu^ 
situation y^hm a billiog number Is obtained by unaidfaorized usets and is used 
illegally to make simultaneous calls. 
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This scenario involves a specified number of oompleted odls * A* within 
a time period *Y* havii« different originating NPA, w NPA/NXX and/or 
ANl. In ottier words, there are a series (^completed calls that have occurred 
on a particular billing number widiin a ^lecifled time period which are ftom 
diffettm originating location that exceed thresbolds set fat originating 
locations. This fraud condition occurs typically whm a Ullliig number has 
been obtained by an unauthorized user and bu been distributed geographically 
so d»c diffennit unauthorlmt usm in different locations use die bUIiog 
number widiin a ^wdfied time period. The unauthorized users attmpt not to 
make simultaneous calls so as to elude detection tiuu fraud scenario. 
Instead, die strategy is to utilize die billing number ftrom difhrem geograpMcai 
locations in a sequential nK>dc so as to avoid flnsud detection and/or 
inevnitifm. Thi9 tnati aoenar^^ in arcordanoe with the present invention 
delects and/or prevems diis fraud fnmi taking |4ace. 

Referring now to Fig. 188, Rg. 175, and Rg. 179, tids fraud scenario 
of anomalous calls on a billing number is described. Fig. 188 is a block 
(fiagram allowing die representative steps of tills fnuid scenario. Astartofcall 
message PA182 is received fhun BSRVR BA108A. The fraud system PB1Q2 
stores die start 19 call message PA182 in SBIRFILE PAl 10. The anoroakws 
call parameters for the lulling number of die call are obtained from die BNU 
record FRAUD4S0 for diat billit^ nunter in BNUFILB PAl 12. Hiis is 
indicated by a boa PO450. These parametm are obtained 1^ kioklng at die 
mginating numbers of die last *N* calls fnmd in field P04SO of U«(U record 
PO450 for die billing number. 

Any direshold for diat billing number In connection widi an originatii« 
call NPA, or NPA/NXX, and/or an ANl stored in die BNUTHRS PAl 14 is 
dien obtained. A decision block determines if diere are any duesholds for 
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theie originatiiv call pttimelen, ^ If 
BNUTHRS PAIU does not have any aich panmeien or thresholds for tta 
billing mimber in oonnecticni witfi (he orjgifBtiqg Dumber, this ftaud detecdoo 
scenario is completed, as indicaled by DONE black PQ106. 

5 Alternately, if decision block PR304 detennines dnt dm is a 

threshold for one or mors of the originating ntwiber panunden, then the fraud 
scenario proceeds to a dedslon blodc PR306. Dedslon bkidc nt306 
determines whether the anomalous originating call parameters eciual or eaoeed 
die duesbolds from BNUTHRS PAl 14, IfdiecuRentiunge, as indicaled by 

10 die panuneters, does not equal or exceed d» dueshoUa, then the fraud 

scenario has not been detected. Ttds fraud aoenario dm pro c eeds to DONE 
block PQ106. 

Ahemadvely , if decision block ^306 detennines diat die current usage 
parameters are equal to or have exceeded the thresholds, then the anomalous 

IS calls on a billhi^ number scenario has been detected, as indicaled by a YES 

flow line PiG08* This anomalous calls on a UUiqg number idarm is ttien 
generated, as indicated by a bkidc PR310. Two acdvides dten tske plaoe. 
First, die anonnlous calls on a billii^ number akrm PA 170 is pr ese n t ed to die 
fraud administntor at die fhuidoonaole(s)PBIOtL Inaddhios, dieanomikms 

20 calls on a blllii« number alarm data is stored in BNUALARMS PAl 16 for 

later use. 

In diisway, diis fraud scenario can detect and/or prevem die ooodltkm 
where diere are anomakiua calls on a billing number wiMa a qmified period 
of time which exceed direshokis baaed on die originating numbers. 

25 7.4.2.7 iiUm^hmi iiumdmg or ikUgalMg COk 
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This fraud locMrio in aooordanoe with the pment invMion detects all 
coinpkled calls which are coming from an internatkmal origiimting number or 
are going to an iniemationallBrminiting number. intenvlkNad* as used here 
means that the call is outside of m specific geographical aieadwt is defined as 
domesdc to U.S.A. All calls outside of this geographical ana are 
demMninated as inlemstional. Typically* 'imemationai' designation involves 
political boundaries* comlnemal boundaries, or land boundaries. 

This scenario in accoidanoe with the present invention detects and/or 
pnivents fnuid that ^ically results in signifiauit financial losses Theseh^ 
losses are due to die tet dukt international calU are expensive. This fraud 
scmrk) detects die occurrence of an imemadonalcalllmmediaiely after it has 
been comptaed, but before it is terminated. In this way* d» ftaud 
administrator can take whatever apprepriate action is necessary. 

It should be noted diat the fraud scenario set fbitt in Rg. 189 is 
carried out to determine if an incoming call is from an intemadonBl locadon. 
The finnd scenario is also separately carried out to determine whtthn* an 
outgoing call is to an international location. Thus, all oompleied calls typically 
are reviewed by this fraud scenario in accordance with die present invention. 

Reference is made to Hg. 189, Fig. 17S, and Hg. 179. Pig. 189 Is a 
block diagram showing die steps of diis fraud scenario in accoidanoe wttti die 
present invendon. Referrii^ now to die figures, a start of call message PA182 
Is provided BSRVR BA108A. The imemational patameten of die call are 
obtained* as indicated by a blocic PR4Q5, fimndteendreori^nadiv number 
Cincludiqg oountiy code). A ded^ block PR4(M determines whedter an 
international flag las been let. This flag is sn)red in dwBNUTHRS PAIR 
It allows die fraud system PB1Q2 of die present invendon to be configured to 
detect international calls. 
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If an intenntkinal fli« b tiot set, dian fniM^ 
ccmfigured to detect intmitioi^ | 
PR406. The imematkmal inooming call fraud aoenrio dm proceeds to 
DONE block PQ106. 

5 Alteniatdyjfdediion block PR404 detects diat an imen^ 

has been set, it proceeds to YES flow line PR4CM. The jurisdicdon of die 
inooming call is dien checked, as tndicaied by a block Flt410. The 
Jurisdicdon amies in die start of call niessi^PAlS2. Ncit, adectsk»bkick 
PIU12detennines if die call based on its Jurisdicdon is Internaiioaal. If die 

10 call is detemined not to be interaadonal (also denominated dmnesdc), dien die 

firaud scenario proceeds aloQg a NO fkiw line PR414 to DONE boa PQ106. 
TMs indkates diat die call has been detennined not to be imernadonal, and 
dius die fraud scenario hu not occuned. 

Aheinadvdy, if decision block PR414 detennines diat die call is 
IS imernadonal, die fhuid scenario proceeds to a YES flow line PR416. This 

indicates diat an imernadonal call hu bem detected. The imernadonal 
inooming alarm is dien generated, u indicmed by a bkxdc PR418. TWo 
acdvides take plaoe. Pim, die Immadonal Inoondqg fraud abmn PA170 is 
provided to dwfnuidadminiMrtorm die fbud consols) PB106. Inadtfltion, 
20 die internttional fraud alann is stored in die BNUALARM^ 

review and analysis. 

The fraud sonario for otttgmng imernatkiial calb is die sanM widi ^ 
exception that it is peifuiiued on the outgoing call. 

Indiis way, die imernadonal inooming or outgnng call aoenaiio of die 
25 presem invention can provide infbnnadon to die fraud administntor at die 

beginning of die call as to whedier die call is coming from an imernmional 
location or gmng to an internadcmal kicadon. Tius information provides die 
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fnud administmior with the ability to talce apprapriaie action befim the 
oonptetedcalllsteminated. In diii way, sigidficam fraud saWngs can result. 

This aoenario in aoocmSanoe with the present invention is directed to 

5 fiBUd which occun when an unauthoriad user has gained access imo the 

tekphcme syAm vaing an unauthmiaed bilHi^ mnnber and is able to make 
repeated telephone calls widuwt havii« to out of the system. For 
authorised user oonvemence, teleidione qrsiems typically bidude a fjeatsre 
which allows for more than one call to be made once all of the Mlling 

10 infonnati(m has been provided if the authorittd user issues proper omunandi 

so as to originate the addttional calls. This capability spares the authorlnd 
user fkom having to repeat the necessary billing inftmnatkm for each call. 
Instead, the billhig infbrmation is provided by the authcffiaed user at the 
beginniqg of the sequence of calls, and does not have to be repeated until the 

15 authoriied user geu out of the system. Hadcers and other unauthorized users 

prefer this mode of unaudioriied use of die phone system because th^ only 
have to provide the billing Infimnation once and because, in nmay traditional 
systems, the information Is only verified die first time. This finud scenario 
In accordance with the present invention allows fbr detection and/or prevention 

20 of diis fraud scenario by an unaudioriaed user. 

Reference is now made to Pig. 190, Fig. 175, and Fig. 179. Pig. 190 
is a block diagram showing die steps of diis fraud scenario. Referring now 
to die figures, the start of call message PA182 is received from BSRVR 
BA108A by fraud system PB102. Thereafker, die reorigination parameters are 
25 obtained fnm the BNU record P04SO fbr die blllliv number In question, as 

indicated by a block PR5Q2. The last 'N* calb contained in field P(MS2 are 
examined to determine diese reoriginatton paranMers of die calls. 
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A dednon block PRS04 detenninei whether reonginadon thndiolds 
are set This ihieshold informatbii ii comained in BNUTHRS PA114. 
Typically, these thmhokls are let fior a certain number of calli which occur 
sequemialiy, without the caller having to hai^g up, re-dial die destinition 
number and re-enter the billing number. A representative threMd b five 
calls. Thus, in acoonlanoe witfi this threshold vahie, every dme five calls 
occur on a sii^ onginition, a fraud scenario is d^ected by die pteiBat 
invendott. If no itoriglnadon direshoM is determined by ded^ blodcs 
PR504, die firtud scenario proceeds to a NO flow line PRS06. Thereafler, die 
fraud scenario is completBd, u indicated by DONE boi PQ106. 

If rec^ginadcNi diresholds have been aet« dits is iadteated by a YES 
flow line PRS08. Thereafto. a decision block PRSIO determim whedier die 
rtorlglnadon paruneters (ooum) of btock PRSQ2 are equal to or greater dian 
die diTBshokte of PR504 obtaiiMd ham BNUTHRS PA114. If die 
IS reoriginadon count is not equal to or is less dian die duesholds, diis is 

indteatedbyaN0fkywlinePRS12* The rear^;inatloD ftaud scenario has not 
been detected, and die fkm proceeds lo DONE bkxk PQI06. 

Alternately, if decision bkick PRSIO determines diat die or^ginadon 
count is equal to or greater dum die dueshokis, Ihb fkiw is indicated by a 

20 YES fkyw line PR514. Itocaftor, die reoriginadon ftaud soenarto alarm is 

genenued, as indkated by a bkxdc PRS16. Two acdvlties ttke place. The 
reoriginadon alarm PA170 is provided to die fkaud adnniustiilor on die 
consoleC) PB106. In addidon, die reoriginndai alarm data is stored in die 
BNUALARMSPAil6 for later use and analysis. The flow dien proceeds to 

25 DONE box PQ10& 

In diis way , a reoriginadon ahurm is provided to die fnnid adrohdstrstor 
each dme die number of reoriglnadons exceeds a vahie direshoU. If die 
dircsboM IS exceeded imnt dian once, die reoriginadon alann is tooM 
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time it is cioeedBd. In this wiy, die ftuid adminlstntor can take the 
neoessaiy action to determine whether a aeries of calls based on a siogte 
UUing nuiriber access to die system are audioriaed or unaitthoriaed. This 
results in reducing fhuid losses significamly. 

This fraud scenario is directed at determining when a completed call 
exceeds a predemrnined lengdi of time, TUs conditicm can be detected in 
accordance with the present invendon ddier Airii^ die completed call or after 
die completed call is terminated. In smne siniadoos involving a loog call, die 
amditbn can occur one or more dmes duiing the call and again after die call 
is finished. This f^ scenario is detected afker die start of die call and die 
expiration of a predetermined amount of dme * Y* measured ffom die start of 
die call. Reference now is made lo Figs. 175. Pig. 191. and 1%. 179. Fig. 
191 is a blodc diagram of die steps of dwloi^duiadon call fraud scenario in 
accordance widi the presem invention. 

The purpose of diis fraud scenario in accordance with die present 
invendon is to detect when a completed call lasts loi^ dien a predefined 
leqgdi of dme. If diis kmg duration call h finudulait, it will cost die carrier 
a significant amount of money. Consequendy. diis fraud scenario is 
performed to allow die fraud admniistratar to take an>rapriate action if she 
determines dnt fraud is taking place. It also allows die fraud admiiustrator to 
take action iigainst sub seq ye nt attempts. 

The intermediatB-lcmg call message PA180 is provMed dinmghout die 
completed call until die call is terminated. The hilermediate-long call PA180 
is provided to die f^ system PB1Q2, as indkaued by a bk)ckPS102. Note 
diat diis intermediate-kmg call message may be provided on successive 
occasions during n completed call diat is of a bng time durati<m. This fraud 
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toenario will be Rpettsd each dme thl) intmediate-long all roemse it 
received. In addition, as diacuned b^o^^ ^ i^^g ^i^tion fhuid nenaiio 
will be peifkiniied after die compteted tennioaied ifion reoeipc of die 
end of call roentge PA178. 

The paranieteri fior die imermedia)e4oiy iloiii^ 
indicaied by die blodc PS104. The^ pmnieien are obtained ftom 
BNUTHRSPA114. NeiU, a dedsion bhici^ psiQ5 ^^^^ 
is a dirediold in die BNU ALARMS PA116 for intennedtale-iong duration 
calls. A typical value is 30 mlsmtei. If d^iiQiibloGk PS106 determines diat 
no uch direihold is set, thefnud soenartQ qy^t^i| fi| gf | ^fi^f proc ffd t to the 
NO flow line UbdedPSlOB. TIsefvuidseeBuiodienimioeedsioDONEbm 
PQ106. 

Attemtfely. if die decision block ^si06detetminM diaia diieshold is 
sel, as indicued 1^ die YES flow Une PShq^ ^ aoenaiio proceeds to 
aded^blockPSlll DedilonMock|isii2drterminBsif diepararoeten 
(diat is, dme liq^) of die tmermediaie-Hi,^ dundcn call from block PS104 
are ecpial to or greater dian die diieshohhfhmidedsionbk^ Ifdie 
parameters are less duui die diresholds, ^ Imermediaie-loog duradon calls 
fraud scenario hu not been detected. 'H^ is indicated by die NO fkm line 
labeled PS114. The interniediaie-kiQ| <totidon call fraud scenario is 
completed and proceeds 10 DOhfE block PQ105, 

Alternately, if decision btock PSU2 determines dot die parameters of 
die intermedlaie4oqg duration call are eq^^ 10 gioater dmn die dued^^ 
die scenark) proceeds to die YES fkiwlti^pSti6. The alarm indicating diu 
immnediate-kwg durukm call is dien (eneiatod, as indicated by a blodc 
PS118. Two activides dten take pinoe. The imerme^ate-kx^ duratum call 
alarm PA170 is pnmded to die fraud Mminisnator at die fraud conaole(s) 
PB106. This allows die fraud administra^ ^ determine in real time dot dus 
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o&toiQg call hu exceeded die time limte aet for the dctecdon of Oiii fnud 
nenerioandlolakeipimipriaieactl^ Inaddttlon, 
die intemediiieJoag dundkm call alaim data \^ provided to die 
BNUALARMS PAH6 fbr sioiage and later analysis. Thereafter, die fnud 
aoenario is comiileted, u indkattd by DONB block I^qio^, 

As staled idiove. diis iiilennediatfr4(mg dui^ 
aoenark> is detected at each imim in time durtiv a oompj^ ^] ^li^ ^ 
exceeds die value diieshold. Ttuis, for exan^, if die value direshold is 10- 
minutes, and the call has been in existone (oontplet^^ for more than 20- 
minutes, two intermediate-loQg duiadon call alarms ^in i^y^ oocuned, mt 

at die 10 roinme mark of die call, and a second at die 20 minute mark of die 
cd!. In addidoii, as discussed betaw.dieie will also be a ddrdlntermetfi^ 
toi^ duration call alarm at die end of die compleied cay |f ^ diieshold 
for diat parameter hu also been exceeded by die call. 



The fraud aoenario for imermedttte-tong dundon calls Is iIbd 
performed at the termination of the completed call. A|| 0f the steps set forth 

in Pig. 191 aie performed at die end of die call after ttcdpt of die END OF 
CALL MESSAGE PA176 by die finud system PBlQj, Since die steps are 
essentially die same as dme for nuRdtoring die duration ^ |^ 

progress, no additional discussion is provided exo^pt that it should be 
understood diat die time direshdd(s) for die end of di^ ^| |^ differem 
finmi die time dueshoklis) for die call dut is In Riqgi^ 

In tills way. diis fnud scenario allows die fr^ud administrator to 
determine in real time If an iniermediate-hmg duration call ia occurrii^. This 
allows her to lake appropriate action in terms of fraud detection and/or 
prevention* 
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The call cost (wholesale and retail) fiBud scenario of the pmem 
invention allows the fhiud administnuor to determine if the oott of a call that 
has been compteted and has lenninated eaoeeds a numetaiy threshold. The 
5 anKNint of both wholesale and r^l costs can be monitored in real time, and 

different thteahotds can be set for each. In thm way, the i»eaent invention 
allows for fraud detection and/or pievemlon of completed calls ciceeding 
certain monetary amouirts. 

Typically, fnudulem calk are of long duiition and of high monetary 
10 cost Such calls provide great economic benefit to the hacter. The hacker 

knows that numerous calls attract the attention of a carrier's Securi^ 
Departmem and will result in the card being deactivated. But a call in process 
doesn't usinlly get reported until the call Is over in traditional systems. For 
this reason, this fraud scenario of the preaem invention alkiws die fiaud 
IS administrate' to monitor on a teal-time basis die cost of a omqdeted caU diat 

exceeds a monetary dtrediokl so that appro|maie action can be taken to protea 
the telecommunications system. 

Typically, this fraud scenario is used fsx international calls which are 
of high cost per minute of calliQg time. However, this fraud scenario can atoo 
20 be used for k)cal (domestic) calls where the calls are less cosdy. 

Reference b now made to Fig. 175, Fig. 179, and Fig. 192. Fig. 192 
is a block diagram of die steps of diia call cost fraud scenario. 

This fraud scenario cannot be p e rformed until after die conq>leted call 
terminates. At diat time, rated call data PA172 is provided by rating system 
75 LA102 to fraud system PB1Q2. This step is indicated by a block PS2a2. The 

parameters of die rated call data are dien obtained, from BNUTHRS PA114 
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as indicated by a bUxk PS204. The parameters of the call cost data can 
include wholesale cost« retail cost, or both. It should be understood that the 
present invention can nnonitor one or both of these costs for each call thi t is 
completed and is terminated. 

A decision block PS206 determines if there are thresholds set for nttail 
cost and for wholesale cost of the call These retail cost and wholesale ^yxt 
diresholds are found in BNUTHRS PA 114. If no thresholds are found, the 
fraud scenario has been completed, as indicated by a NO flow line PS208. 
The fraud scenario then moves to the DONE block PQ106. 

Alternately, if a latail cost threshold and/or a wholesale cost thres^iold 
is found, the firaud scenario proceeds to a YES flow line PS210. Next, a 
decision block PS212 determines if the cost parametera (at wholesale and 
retail) of the completed call that is terminated are greater dum the 
corresponding wholesale or retail thresholds. If none of the thresholds that are 
in BNUTHRS PAl 14 have been exceeded (wholesale and/or retail), the fraud 
condition has not been detected. The fraud scenario then moves to a NO flow 
line PS214. The fraud scenario then moves to DONE blodc PQ106. 

If decision block PS212 determines that either or both of the retail and 
wholesale thresholds have been exceeded, die fraud scenario has been 
detected, and die flow proceeds to a YES flow line PS216. The corresponding 
alarm, which can be either a wholesale cost alarm or a retail cost alarm or 
both, are dten generated. This is indicated by a block PS2 18. Two activities 
then occur. The wholesale cost alarm PA170 or die retail cost alarm PA170 
or both, depending on which has been generated, is provitted to the fraud 
administrator at fraud console(s) PB106. This alarm(s) PA170 allows the 
fraud administrator to take appropriate action concerning future calls. This is 
especially important for international calls, since this allows her to take 
appropriate action to prevent additional international calls which are 
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unautborixed. While not all inlernatkml calls are fiaudttleitt, moat long 
dufation high cott calli are teudulait Ugitiinaie men tend lo keep long- 
diiMoe calls vdativdyihoA In leagdi. In adAtion, the wholesale fraud alarm 
and die lecail fraud alarm or both (dqseadiqg on which has been generated) 
aie provided to die BNUAIARMS PA 1 16 for stonge and sidiaec^^ 

h ihould be understood diat the fnuid system PB102 can be cuslomU 
to monitor the wholesale and retail coit of all calls cm a real-time basis after 
die oomiHMd calls are terminated. Altemadvely. only particidar or ipedfied 
calbcanbemonttomd, Indus way. die fiuid administrator can detect and/or 
prevem fnudulem acdvides by imaiUhoriad users based on die cost of the 
calls, whidi results in significant cost savings. 

7.4.3 SimOlmumaika^mEmigNmabtr 

This fraud scenario detects and/or prevents simultaneous uses of a 
billii«nunAer. It prevema over charging of calls to a Ulling number. Ptaud 
system PBlttt uses messages firom BSRVR BAlOftA and messsg^ 10 ami In^ 
validatioo system AG102 to provide dds fraud scenaria 

Reference is made to Fign. 175, 193, and 195. Fig. 193 is a block 
di«gram showli« die flow between fraud system PB1Q2, validation sysmn 
AGlQ2,andBSRVRBA108A. F«. 194 isabkxdc diagram ofdie steps in die 
fraud scenario involving die validation system AG102. Fig. 195 is a block 
diagmm of die steps in die fraud sceoarfo involving BSRVR BA108A. 

In order to prevent simultaneous uses of a lulling number, die 
CHNDHLE module PA118 was developed. There are certain bunness 
simations where it is in^rtant id ensure diat diere is only one use of a billhig 
nundier at a time. An example is die Debit Card product. whk:h is a card 
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laving a immeiuy tmoum that can be deciemei^ 
to pay fior calls. Became the debk card is monitored for when it has expired 
(thatis,decreinemedto»mrHnainingmonetaiyba)anoe), only one use of the 
billli« number of the debit card can occur at a time. This capability is needed 
because BSRVR BA108A tracks an active Debit Card call and cuts it off after 
die Debit Card hu expired. 

The current number of uses (rfa billing number is kept in a record 
(field) in die BNU PO4S0 record fbr die bilUng number. BNU P04SO file 
lecord is stored in BNUFILB module PAn2. This nuniber of uses of a 
billing mimber is incremented from a message PC104 coming from validation 
systm AQ1Q2, and decrem en ted fifom a message PZ1Q2 omning from BSRVR 
BA108A. BSRVR BA108A does not have die billing number of die call id 
look h up in BNUFILE PAl 12, but it does have a unique callhandie BA3QSftir 
die call. Thersftyre, CHANDPILE PAl 18 was supplies die connection 
between callhandie BA3Q5 and the billing number of die current call. 

Referring now to Fig. IM, validator system AQ102 sends an increment 
bill number uses message PC104 to fraud system PB1Q2, as indicated by a 
btock PZ104. When die Increment bill number uses message PC104 is 
received, die billing number is searched fbr in BNUFILB PAl 12, as iodicated 
by a bkKk PZi06. As indteatod by a decision bkick PZ108, if die BNU 
record is not found, as indicated by a NO fhiw line PZllO, a new BNU 
reccmi is created based on die billing number, as Indicaied by a Mock PZI 12. 
The fiaud scenario proceeds via a YES flow line PZl 14 to a step PZl 16. The 
current nundier of uses is dien incremented in this new or searched BNU 
record as indicated by a bkick PZ116. 

At diis dme, a callhandie record PZ124 is created and med in 
CHANDHLE PAl 18, as indicated by a bkick PZI 18. The inficmnattcm stored 
in callhandie record PZ124 includes Uie callhandie BA3QS and billing number 

1462.0010000 



.^^16462 

of the current call. TkU callhaniDe nooid PZ124 is needed later when 
BSRVR BA108A aends a de cre m en l number of Inll number uses messafe 
PZ1Q2 to decrement the number of uses. 

Once step PZ116 is compteced, a message PZI29 oomainiog the new 
5 number of dmultaneous uses is sent to the validator system AG1(12, as 

imficatedbyabiocicPZllO. 

Referrii^ now to Rg. IM, when a d e crem ent number of Mil number 
uses messages PZ102 from BSRVR BA108A is nodved. u indicated liy \a 
blodc PZ130, the callhandle BASQS fai the request nm^ U used to seaich 

10 CHANDPILE PA 1 18 to retrieve the billing wimber of the call just oonqileted. 

u indicated by a bloclcPZ132A. AsthownbyadecisianbhidcPZ136,if die 
billfaig number is not lbund» the ftaud scenario is compieied, as indicaied by 
aDONEUodcPZI37. If, however* die reconlaiBlBiniivdteWliog number 
is found, as indicated by a YES flow line t213S, it is used to loolt up a BNU 

IS record in BNUHLE PA112 usfa« the IHIiiqg number localed in die 

CHANDPILE PAl 18 record, as indicaied by a blodt PZ140. 

As indicaied by a decision blodc PZ142, if a BNU reooid is found in 
die BNUFILE PA 1 12, die current number of simultaneous uses is de crem e n ted 
if it b greater dien 1, as indicated by a blodc PZ148. If it is not found, u 
20 indicated by a NO flow line PZ144, the flow proceeds to step PZISO. 

Since there now is no cunem or foture use for the cecoid foimd in die 
CHANDHLEPA118,itisdeleted,astndicattdbyblodcPZ130. StepPZlSO 
compleCBS die steps in the flow of die received message, as indicated by 
DONE bkxdt PZ150. 

25 In diis fraud scenario, die ability to aocuntely momtor die current 

number of uses of a bilHi^ number ensbtes the validation system AG107 to 
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block more ten one simultuieous we of a billing number. In te pnsem 
entediment, DeUt Cudi are an eumple of a situadwi wbere use muit be 
restrided only one current ure <rf a billing number. TTds fraud Boenarlo, 
however, does not need to be limited to DeUt Cardi, and enoompatm any 
S applicadim Involving limultaneous uae of a biding number. 

K repreaentative gnphlcal uier intertee (QUI) for a firaud conaole 
PB106 is shown in Fig. 203 and described below. TMs is a represenlatfve 
QUI, ami te present inventioo oonmmplatBS any suitable display of 

10 infonnation now prssem or hoer developed diat assists te 

in detection ami/or preevendon of fhnid. The eaample embodimem shown 
bdow lUustrstes te types of InfSonnation that can be provided to te ftaud 
adminisdnior, and die Idnds of Imerictions that the finuid admhi^^ 
with te fraud lysiem PB102 in connection widi firaud detection and/or 

15 prevention. 

The main screen shown in IHg. 203 is divided into an upper pordon fbr 
tebilied mimber usage (labeled ALARM TYPE and exteodii^ down to BNU 
ALARMS, and a lower pordon fbr te foiled Irill number atarms Qabeled 
ALARM TYPE and extending down to FNB HOT ORIQ). The top portion 

20 of the screen Ubded "Fraud Motdtor" gives die maintenance infbrmation 

about the system. The current day and time are diq>Iayed, as well as how 
h>qg te system has been ninnlQg whbout Intemption. If, fbr some reaion, 
dte system has been disabled, te BNU ALARM STATUS will ahow that 
ocmtUtion. If dds should occur for more dun a few seconds, an alarm will 

25 sound in te Network Opendons Center <mte Log BoK. Thisisaprecaudon 

to ensure that te system is operadng at peak efndency and to ensure that no 
atarms are missed, causing unnecessary losses to go undetected. 
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TheiyiiBin it designed to be extrerody uter-firiendly u wdl u dm^ 
saving. To view an alann. die tatid adminlstnior dmpiy highligbti die 
itoofd viaacunorandpitsaesENlllt A ALARM DETAIL INFO icnen, 
as shown In Fig. 201, will "pop up" into die main icnen. This pieliminaiy 
5 screen ^ves very basic Infidrmation dxxit die type of alarm bdng viewed. 

When more dian one call triggers an alarm, tach call will be listed by BIR ID 
inthisscieen. ftuther detail, pressii^ENTBR will bring up anodier "pop 
up" window tided Fhmd Short BIR INFO, as shown in Fig. 2Q2, which 
contains die actual call detdl record of the call. 

10 7.5.1 nmMdr 

Thresholds may be viewed or established for individual customers or 
for global situations. To view die current diresboMs, die (BNU TRRgl field 
of Pig. 203 is selected. Thb providBS acoeess to ALARM THRESHOLDS 
DETAIL INFO scieen of Fig. 196. Esch set of parameters is avaiUUe for 
IS viewing or updating. The Defiuilt Ghibal pammelers are for cards and for 

opecaior services. The individual Threshold Key field allows for oustomiml 
diredkolds for specific accounts. The screen will indicate what pammelers m 
set, and die lone and dumtioo of die alarms. 

Parameters widi bradocts (1 0 indicate a yes or no threshold cmidttion. 
20 To activate, die E^^Il]t key is pressed afkrhiglilightiiQ die brMketwidid^ 

cursor. A / will appear in die bracket To deactivate, die ENTER key is 
depressed again, and die /will dissppear. This aleits die BNU file to check 
certain fields to see if a panmeter has been set 

The Tones and Durttion setting is set to establish what pitch die alarm 
25 win sound and how long it will beep. Moat parameters are set wtdi a duration 

of 100nis,butmaybesetforask>ngas300ms. The tone settings may be set 
from 500hz to 30G0hz. This alkvws for compleie flexibility in cusKmiizing 
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alanns on a customer-tay-custoiner buBi. It also allows die administmlor to 
set pitches aooofding to her own heariog capabilities; many people do not hear 
certain decibel levels or tones due to hearing loss or interfersnoe. 

teameien must be established for boA d» BNU as shown in Fig. 

5 196, and the FBN, Fig. 1%A. Hds Is true of die Hoi OriginadQg and Hot 

Terminating ANI alarms since diese alarms eaisl for bodi completed calls and 
biled calls. Once die parameters are set, it is neceswy to enter die billing 
numbers and origiradqg or terminadog ANI*s diat are id be specifically 
monitored. The system will globally monitiv all billing muntbers, however, 

10 customers will often request sperialiwi parameters. These special numbeis 

are die ones dud must be keyed individuaily. 

The[BIUlilUMSlicreni,asdKywninPig. 19? is used to enter dieae 
cusiomisBd numbers. It also allows die ftaud administntor to seareh die 
system to see if a particular type of call has been made or to see if a particular 
IS billing number has been used to make a call. The arrow keys on die keyboard 

are used to select a billing mediod for which to set a parameter. Tbeavaihd»le 
fields, for eaanqiKe, are: 



800 NUMBER 800 PIN AM» EXPRESS 

ANI CALLED NUM CAN LBC CARD 

20 DEBIT CARD DINERS CLUB DISCOVER 

LECCARD MASTERCARD NOT USED 

PCC THIRD PARTY UNKNOWN 

VERIF REFUSED VISA 



Once a tHiling mediod is chosen, the Billing Niuhber field of Fig. 197 
25 is used to key in die number to be enteitd into die llirahold screen Ftg. 196. 

The tyutm is oonflgurBd to make sure die number is not already enteted to 
avoid duplication of records. If a duplkation exists, a pcp-up screen will 
appear and show die currem records for diat billing nuniber. If die billing 
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numbn' doei DM appear in the qfitm, h alkiwi te 

theayttem. A "Suootts'wiiKlowwiUope&toindkaCBtaiiiipleie^ To 

remove a billiqg number fiom the system, the fnud adminisoitor simply 

Mkim the same procedures and uses the afiedfic functioo key to delete die 

reooid. 

7.U Stmh 

FhKtt the main screm, Fig. 203, the system provides the aMlhy to look 
atthetoilhistoiyofanybiltii^mmiberorANIintwoways. Onrw^fisby 
iisli« the imRq fieU; the odier the pmMJl^ 
, as shown in Fig. 198, die ifystem will briqg up all BURS, from die dme 
requested, or it wiU start at die EIR ipedffed ani show evciydd 
By presriiv die ENTER key, a fRAUD SBQitT BOt INTO screen, u 
shown In Fig. 200, will open and show dn call record «pecifM. 

InoPder loddennine if die sydem hu call detail to a specific UUed 
numberoraqyof die above listed criteria, die BILLNUMSacreoi, Fig. 197 
Is used. The fraud adminitfrator may select from die apprapriaie criteria 
whidi fieM she wiriies to search, enter dlie bUling miihber needed, and by 
pressing a ^ledfic function key, see all of die call detail stored in the database 
which maicfaes dw search crit^ This mednd is fiuter dam that used in 
tnuHdond systems, which involves nuudng a aeareh on a switch database. In 
comiast, the presem invemion causes less sti^ on die call processing speed 
of die switch, which is ahmys inqncted whma ret|uest for call detail i^ 

hMBObiNmikirSafun 

The FBN screens are used exacdy die same as are die BNU screens of 
Fig. 197 and 198. Oonsequmdy, die only difference between dieae is 
dscussed. The FBN screen only shows calls diat Mled ftv some reason. The 
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call failure may have oocuntd because Ihe Inlliog number was invalid, the 
validation aervioe wai not returning the oonect informiition, or lome odier 
reaaon as diacutaed ehewhere. 

T6 view an alarm, the fraud administrator moves the cumr to 
highlight the leoord and presses ENTBIL An ALARM DETAIL INFO screen 
will "pop up" into die main screen. A represiMitative of diis is tiiown in Fig. 
20L 

When more dian one call triggers an ahirm, each call will be listed by 
BIR ID on the scrt«i of Pig. 201. Tlie fhuid admlnistrBtor highlights the call 
she wishes to view, and pTones OflER to tother examine the call reoo^ 
this ahum. Relbrring again to Pig. 200, a "pop up" screen will dispby die 
BIR INFO fiar die call. 

7.5.5 AEflbv Ike Siiitni 

To exit any of the pop-up screens, the ftaud administnUor presses 
fESQape back to the main screen. To exit dw entire system, she hig^lig^ts 
die EXIT field and presses ENTER. 

7.§ RgporU 

The Real Time System reports on calls as soon as dtey break the pre- 
set direshoUs* but die Batch Reporting System provides an exoeltent badc<*up 
and caich-all for the Fraud Department. These reports are printed for 
spedfied dme fnunes, or can be demand-selected at a momnits nodoe. This 
provides great flexibiliqr for die fraud administrttor, who, while looldi^ at 
somediing on die Freud Monitor, may dien query die database for further 
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documemitioii, Documenntkm is iwoemry for evidentliry lopone in 
invesdgatiiig ftuid inddems. What foltowt is a genenl description of die 
reports generated by die ftiud system. 

7.6.1 Bxetutm Uiag§ 



This fcpm is soited in a nuniber of diffismnt ways which assistt in 
identifying unusual calling patterns. The finaud^fsiem allows tfilsicport to be 
queried or baich-rcportBd at apectfied dme frames. The detail shows: 



Date Ulltng 

Time Access Nundier 

Dunolon BIR ID 

OrigNuniber fReoriginated 

DialedNumber Terminating Status 

Billed To Number Termimuing Call Method 



The icportt can be sorted by Originadng ANl, Tennlnntiqg Number, 
or Billed To Number. Many dmes differem Originatii« ANI*s will show 
numr 'vus calls to die same terminating number, but die bUllog number will 
be diffemit each time. If die report oidy kxiked at die billing munber sort, 
it is possible tint a fraud admimstnUDr would miss the usage. Butbyhaving 
die multiple sorts, die chances of missing an importam fraud incident will be 
reduced. 

7.C2 ficetisAw Dlwatfaa 



This report Iceys off die kmg duration portion of die system and reports 
any call over one hour in duration. The fields are die same as above, and die 
sort is by duration to shortest Agsin, diis is shnply a back-up to die 
real-time system. If only one or two kyi^ calls oocuned during a given day, 
but were spaced for enongb apart, dw fraud administrator might miss die hct 
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tltttabillii«miiitoinMteaevenl ioi«dundonca^^ This report will ibow 
that ocxnmem as the calls will be giouped togeiber on the page. 

&• GaMMV* 

Can iHooeasliv vflttm ABKQ uses a host gateway &AIIO and a 
customer pteway BAl 12 to ftdlitaie onnniuniGations betweni the processes 
that mate up NCP AB104 and subacribers AA114. As memkmed in the 
HelwoikOQiitid Piooessor SectiOD of this document, host gateway 
customer gateway BA112A perform ooramunkatkms format and/or pratoool 
ooB VOT io na so thtt NCP ABIQ2 can oommunkate with subseriben AA114 
and mstris twiieh ABI06. 

The types ofcommunicatlons formats and protocols used by subscribers 
AAIM, NCP ABIM, and roatrii awilch AB106 dictates whedm cutfomer 
gateway BA112A and host gateway BAltO are needed, and if so, what 
cornmunlcatlons oonvcvrioas must bt perfovmed. 

fn one embodiment, call data AAI44 and other communications with 
customN switch AA104 and matrix switch AB106 is in die tarn of SS7 
mfftiagcs, such as Initial Address Messages (lAMa), Address Compleie 
Messages (ACMs), Answer Mesnges (ANMs). et cetera. In diis embodimem, 
customer gateway BAl 12 performs oonvensons necessary so that caU data in 
the form of an SS7 messi^ can be communicated across LAN AB12Z. 
Additionally, alternative embodiments are contemplaied wherein SS7 and other 
mesaige 9pes can be interfoced to a NCP AB104 having a communicadons 
format odier than LAN AB122. 

The operatifm of customer gateways BAl 12 and host gateways BAl 10 
is now described in terms of the operation of settiiig up a call, completing a 
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calU and termimtii^ a call in the eirtndimem using SS7 roestnge forroiti. 
The example dncribedls an opentor-asnated call wheiete call is first romed 
through an opeiator console AB108. This exanqik was chosen to ilhntiate 
interaction widi operator consoles AB108. 

Fig. 122nablockdi4gmm ilhistrating the data flow during call setup 
in one embodiment Pig. 123, whidi comprises Pigs. 124 and 12S, is an 
operadtmal flowdingiam ilhistrating the process Miowed during call setup in 
this embodimem. Referring tiaw to Figs. 122 and 123, when a user AA106 
OUttstrated in Pig. 3) ptaces a call, customer switch AA104A generates an 
lAMfl RA102 message. In a step RA202, lAMfl RAKB is received at 
customer gateway BA112A. 

In a step RA20i, customer gateway BA112A converts lAMf I RA1Q2 
to a CALL SE1VP MBSSA(» it RA104 and forwards CALL SEIVP 
MESSAGE fl RA104 to CMP BA102. In step RA204, customer gstew^ 
BA 1 12A performs communications protocob and fcwinat conversions nece 
to ocmvert a stattfaud lAM message to a messnge 9pe dnt can be handled by 
CMPBA1Q2. CMP BA102 forwards CALL SETUP MESSACT#1RA104 
to host gateway BAl 10. Additionslly,OIPDAlQ2perfbrmsodier call setup 
dudes as described above in the Netwoilc Ccmtrol P roc essor Section of diis 
document widi refiBrenoe to Figs. 14. 12, and 13. The CALl. SEItJP 
MESSAGE #1 RA104 also contains die Consde dua has been allocated for 
tbeadl. 

In a step RA206, host gateway BAllO converts CALL SETUP 
MESSAGE #1RA104 to IAMI2RA1(». Host gateway EAl 10 sends IAMI2 
RA106 to matrix switch AB106 and stores die Console Number infonnatioo 
in its tables. lAMfZ RA106 directs matrix switdi AB106 to route call audio 
AAI42 toasQibRA142. Depending on the type of switch used, call audio 
AA 144 is parked at stub RA 142. This is done in die event die call has to be 
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leorigiitttBd. IfthecatlbastobeieoriginatfidJtwillgototaibRAUl^ 
DOttDaomaoleABlOS. This is because if a call needs to be leoriginated, the 
same console AB108 may noc be available to handle chat call upon 
itori^nttioa. In this case, die call is routed to stub RA142 and a new console 
ABIOS asdgned. This allows allocation of the console best suited to handle 
die call. 

In response, in a step RA207« niatrix switch AB106 sends an 1AMf2A 
RAlOft to host gateway BAl 10. In a step RA208. host gateway BAl 10 sends 
an ACMfl RAUO and an ANM#1 RAl 12 to matrix switch AB106. ACMIl 
RAl 10 indlcttes to matrix switch AB106 that IAMI2A RA 108 is nsoeived, the 
audio dfcuit is set up, and die network starts ringliv* In (his case, because 
this Is an opentor assisted call, the call is first routed to an operator console 
ABIOB. ANMf I RAU2 is generated by host gateway BAl 10 because stub 
RA142 U Incapable of generating ANMfl RAl 12. Ineffisct, ANM#1 RAl 12 
tells matrix switch AB106 diat stub RA142 has "answered" tiie call. 

Matrix switch AB106 then semis an ACM message RA130 and ANM 
message RA132 to die ori^natlQg customer switch AA104 via host gateway 
AAl 10 and custtHWtr gateway AAl 12. 

In a step RA324. host gateway BAllO sends call accept message #1 
RA130 and call answer message #1 RA132 to customer gateway BAl 12A. 
This occurs In a step RA324. 

In a step RA326, customer gateway BA112A sends ACMf3 and 
ANMI3 RA134 and ANM#3 RA136 to customer switch AAI04. This 
indicates that the call has been answered 0>y an opentw console ABIOS). 

The host gateway dien retrieves die console number firom its tables, 
translates it to a ten^lgit called number and amstnicts a PAR message widi 
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this inftmrntkm to md to the Matrix Switch. The hoit giteway tends 
FACIUry REQUEST MESSAGE #1 RAl 16 ID the Matrix Switch AB106. 

FACnjrrY RBQUSSTMlSSACXfl RAn6 instnicts mttrix iwilch 
AB106 10 truisfer call audio AA142 horn stidi RAI42 to die oouoie AB108 
identified in FACnJIY RBQUBST MESSAGE #1 RAl 16. In tfaisexanvie, 
FACnJmr REQUECT message fl RA116 li an exan^ of awitch 
omtrol data AB122 (see P|g. 3). 

Matrix swhch AB106 genemies a teility accept measafe RA1I8. 
PKility accept message is an acknowiedgement by matrix switch AB106 that 
It has received fiKdlity request messsce #1 RA116. In a step RA214. host 
gateway BAllO receives teility accept mesme RAllg. 

In a step RA3I6« matrix switch AB106 getmtes a releaae stub 
message RA120. Release stub messi^RAllO is sent lo and received by host 
gateway BAIIO. Releasestubme8S«geRA120indlcaiestfiatcallaiidio AB142 
Is no longer routed to sod) RA142. 

In a step RA318. matrix switch AB106 genentea an lAM 13 RA122 
indicating dnt matrix switch AB106 is reqiiestii« to loute call audio AA142 
to the dwignated cpentor console ABIQ8. Host gateway BAllO receives 
address RA122 and converts it hdo a caD senip mess^ 13 RA124. Host 
gateway BAllO aendscaU setup message #3 RA124 to CHAP BA102, Gall 
setup message #3 RA124 Is in the fonnat recogidaed by CMP BAia2. 

in a step RA322, host gatew^ BAtlO sends ACMI2 RA126 and 
ANMf2 RA128 to matrix swhch AB106. These signals indlcaie that console 
ABIOB has accepted and answeitd die call. In one endKxUment,tfaeae signals 
are triggered by a lesponae RA1S2 from CMP BA1Q2 indicating that it 
received call setup message 13 RA124. 
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M this point, the cftU ia aetup In an operator consoto AB108. The 
human operator at manual opemtor conadle AB132 or the automaied VRU 
AB1S4 can perform whatever operator operations ait necessary to allow the 
call to go through. This can include validations, call mdng. and verifying diat 
a Ahd party is wilUog to aooept call charges. 

Once operator console AB108 has verified diat die call can be routed 
to Its desdnadon, call compiedon takes place. Call compledon is now 
described. Fig. 126 is a data (low diagram lllustradng die messages sent in 
completing die call. Fig. 127 Is an ufiendonal flow diagram llhistrtfing the 
steps followed In oompledog the call. Referring now to P^. 126 and 127, 
inn step RB202, operator console AB108 instructs CMP BA102 tocomplele 
die calK Belbte Instructing CMP BAIOZ to oompkie die call, operator 
console AB108 hu perfbrmed whatever validations or verifications are 
necessary belbre die call will be allowed. 

In a step RB204, CMP BAIQZ sends a call oonqdete message RB102 
to host gioeway BAllO. In preparii^ call complete message RB102, CMP 
BA102 does a database look-up in a termination translation database to obtain 
a route number. 

In a step RB206, host gateway BAliO creates fecility tequett message 
#2 RB104 and sends fadiily request message 12 RBI04 to matrix switch 
AB106. 1^119 request message 12 RBI04 instructs matrix swtldiABi06 to 
transfer call audio AA142 firom the assigned operator console AB108 to die 
number of terminatiqg user AA106A. 

Additionally, matrix switch ABI06 sends a FACmTY ACCEPT 
MESSAGE RBIOS and a RELEASE CONSOLE MESSAC» RB107 to host 
gateway BAl 10. FACILITY ACCEPT RfkS^AGE RB1Q5 indicates diat 
FACILITY REQUEST MESSAGE #2 is receivtd and accepted. RELEASE 
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CX>N50LE MESSAGE RB107 indicitei tlutt the console 

thecftll. IlKsemeutietaitooitveitedaiidfiDnwi^ CMP 

BA1Q2 lendi a mestage to GU) BA106 rekaring oomole. 

Matrix switch AB106 stnds lAMM RB106 lo host gateway SAliO. 
S IAMI4 W106U the inesvgBsem by matrix switch 

to termlmting user AAlOfiB. 

In icapcmse, in a step RB210, host gateway BAllO senrtt CAIX 
SETOP MESSAGE M RB108 to the CMP. Hie CMP then instructs the 
BIllu« Server to add Ae QC to its taUes, and tbrwanls the Call Setup 
10 MesssgB to the Customer Gateway BA112B. 

In a stq> RB212. cammer gateway BA112B sends lAMiS RBI 10 to 
CQstmer swhch AA104B. Thus, in sofis RB210 and RB212, host gsieway 
BAllO and customer gpteway BAI12B aie finwaidtng the 1AM asm from 
mstrix switch AB106 to customer switch AA104B reijuesth^ thai the call be 

15 routed. In response, in a step RB2U, customer switch AAlOiB sends 

ACMM RB112 CO cusumier gateway BA112B. Thb indteates that customer 
switch AA104B has accepted the can. Also in step RB214. when teniansting 
user AA106B answers, customer switch AA104B tetids an ANMf4 RE113 to 
customer giieway BAU2B. This indicates that terminadog user AAlOfiB 

20 answered die caU. 

In a stfp RB216, cusKMner gateway BAl 12B aends a CAIX. ACCEPT 
ME^GE 12 RB 1 14 and a CALL ANS WER MESSAGK it RB 1 1 6 to host 
gatewi^BAliO. CALL ACCEPT MESSACT 12 RBIM is sent in lespcmae 
to ACM 14 RB112 message. CALL ACCEPT MESSAGE §1 RB114 is 
25 intended to indicate to matrix sv hchABlOS that the call 1:3 been aoce^ 

customer switch AA104B. CALL ANSWER MESSAGE #2 RBI 16 is sem 
in Ttsponse to ANMf4, and is intended to indicatB to customer switch 
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AA104A and to matrix twHtb AB106 that lenmnatitv user AA106B hu 
answmd the call. 

So tlwtCAIXACCm MESSAGE 13 MlHnaehetmatri 
AB106. host gtteway BAUO oonvem it to ACMI5 RBI 18 and fb^ 
matrix iwitdk AB106. Similarty, host gateway BAltO convoti CAIl. 
ANSWER MESSAGE 12 RBn6 to ANMiS RB120, and forwards ANMI5 
RB120loinatrixswitcli AB106. Thus, matrix switch AB106 b informed that 
the call has been aooepled by customer switch AA104B, and dm tBrmfawdog 
user AA106B hu answered die call. Now, the call is completed and routed 
ftom originatiiv user AAI06A to terminatiQg user AA106B. Host gateway 
sends a start timiog messsge lo start retail timii^. 

Hie process of idessfa^, or terminating die call is now described. 
Fig. 128 is a data flow diagnm illustrndog die data flow diat occurs when a 
can b tormittsnd. Fig. 129, which oompriaes Pigs. 130 and 131, b an 
operttlonal flow diagram illutfndj^ die iMooess by which a call is terminate 
Referring now to Figs. 128 and 129, in a step RC202, when a user AA106 
hai^ up die phone, or odierwise severs the oonnocdon, a release messsge 
RBUl b generated. In dib exanqde. terminating user AA106B severs die 
connection firtt. In diis esse, customer switch AA104B sends REUl RCIOQ 
to customer gateway BAil2B. 

b req)on8e, in a step RC204, customer gstnway BAl 12B sends CALL 
RELEASE BSQUSSr MESSAGE #1 RC104 to CMP BA102 and sends out 
RLC 12 RC112 message to die customer switch AA104B. CMP BA1Q2 
forwards CALL RELEASE REVEST MESSAGE #1 RC104 to host 
gateway BAllO. CMP BA1(12 also passes messages to odier processes widdn 
NCP AB 104 so dud a BIR EB322 can be updated widi die dme that the call 
wu terminated. 
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In a «qi RC206, host gitmy BAllO mdi IUB1J2 RC106 to 
switch AB106. RBLI2 RC106 iodiattet lo imorix iwitcb ABi06 tet one of 
the uwm AA106 has hu^g op, or the amnecdon has ocherwiK been levmd. 

Matrix switch AB106 Chen leven the otmnocdoii (rfcall audio AA142 
to that the call ii no loi^ lomed to outomer twitch AAlOiB. Matrix 
switch AB106 sends RLCf 1 (release completB) RC108 id host gateway BAl 10 
as a response that it received RBLI2 RC106. This oocun in a step RC206. 

Matrix switch AB106 now needs to release customer switch AA104A 
so that the oonnectkm between customer switch AA104A and matrix switch 
AB106 can be terminated. Theieibre, in a step RC2I4, maOfk switch ABt06 
sends RELI3 RC114 to hott gsteway BAUD for ultimate ttansmisnon to 
customer switch AAKMA. 

In a step RC216, host gateway BAllO oonvats RBLI3 RC114 lo a 
CAlXRELEAS£RBQtJESTMSSSAGEi2RC116. Host gateway BAl 10 
sends CALL RELEASE REQUEST MESSAGE 12 RC1I6 to customer 
gateway BAl 12A. InapieforredendNXttment^CALLRELEASERBQUEST 
MESSAGE 12 RC116 Is sernvk CMP BA102. Apin, this is done so diat 
BIR EE322 fiv die call can be updated and so diat CMP BA102 can delete a 
^icoit Identification code (OC) for the call. 

Host gateway BAUO then geneialea and sends a RRUCASR 
COMPLETE MESSAGE (RLQ M REC224 to matrix switch AB106. 
RLQM REC224 indtcaies that idease of die call is oanpleted. 

In a step RC318, customer gateway BA112A converts CALL 
RELEASE REQUEST MESSAGE 13 RCI16 to an REL#4 RC118 for 
transmisikm to customer stMtdi AA104A. This informs customer switch 
AA104A diat d» call has been ideaaed. 
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In response, cusnuner iwiich AA104A aenda an RLCI3 RC120 co 
oustoroer gateway BAlllA. Thia occun in a itep RC220. RLCf3 RC120 
aekaowtodges that tiie call audio connect^ 
and matrix switch ABt06 has been tenninated. 

M cam Smnr i9U»rflK9 (CUP) 

Gcmventional client servers are usually inovlded with the functionality 
to manage and naimain the oonnectioos with the vaiioitt diems that interfile 
Iheitlo. Additionally, conventional client serven are often leqionsible for 
perfartnlug load sharing amoQg die clients. These overhead functions 
consume valuable server processor time. This time takes away Ihmi die time 
tfatt die server out be used to perfbnn actual server functions such tt database 
look-ups and retrievals. 

The inventors have (Usoovered that in maiqr cases cHems usually have 
more time to perform overhead ftuictioin than do die servers. This is often 
because each server is tyi^lly respcmsiUe fior handlmg numerous clmms. 
Thevefore, die inventors have developed a client/server interteoe (CUF) diat 
operates differently from oonventioiiai diem servers. Acoordlog to the CUF 
of the present invendon, servers are ody respon^ite for handliqg dient 
requests and sending responses to dients. All of die managmnem overhead 
burden is placed on the clients. Hiecliailaniakeallserver requests, manage 
die server connection, perform retries, and odier like functioos. As a readt, 
the server can handle and respond to dient requests more quickly than a 
oonventkmal server, and can even handle mors dients. 

The dient imertee aooordiog to die present invendon Is not limited to 
imerfadng a diem application widi a server applicadoo. The diem interfMe 
Isalsousedtoimer&oe mddple dients. The diem imerfiaoe is mw described 
at a high levd. Fig. 132 is a bigh-levd block diagram itlustratiag die use of 
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the diem interfm aooonliqg to the pitsem invem Referring now to F|g. 
132» each component within call piocesri^g ayiiem AB1Q2 (in other woids 
CMP BA102, MOC Afil32, etc.) hu one or mote applictfioni SA102 to 
perform the ftinctkmali^ of duu component Theie ipplicitioni SA102 cut 
communidte with one another uiing a cUem imertee (CUF) SA104. 
Applkatiotti SAlCn uie CUF SA104 to manage the tnnsfer of mesiages 
between q^lications SA102. Not all applicatltms SA1Q2 lequire a CUF 
SA104 to perform inierftce functions. However, certain beneflta are provided 
by CUP SA104 aa is discussed in diis section of the patent document 

One advam^ of CUP SA 104 pro^des inam«emem of the ooiuectk^ 
between applicadoos SA1Q2. Consider die eumple of an opmtor console 
AB108 requestiiig a validaticm from validation system AO102. In dib 
example, an application SA102 widiin opemtor console AB108 mes a CUF 
SA104 to perform die messi^ transfer In coivunction with a CUF SA104 in 
validatioii system AG102. 

Abhoogh there are numerous cmbotfweats of CUF SA104, one 
embodiment contemplates CUF SA104 mamtging cominumcations am an 
Edieroet LAN. Hiis embodimem is now descr i bed. Fig. 133 is a diagram 
illuatntirig biyen witfiin a dient and a server to handle communications over 
an Etfiemet LAN. Applications SA1Q2 provide die fiuicdoaality of eadi 
particular compooem widi call processing qrsiem AB102. As roendoned, 
SA1Q2 is using CUF SA104 to manage message trsffic between it and odier 
applicatioia SAKQ. Thus, if an a(4>licaKion SA102 has a message in whkh 
to send across a LAN SB122, it provides dds message to CUF SA104 to 
manage d» transfer. 

CUF SA104 performs message management fimcdons as discussed in 
diis aecdrni d die patent document, and forwards die message to a user 
datagram protocol (UDP) layer SAIQZ. UPD Is oommoidy known in die 



1462.0010000 



211616.^ 

^; .268- 

comniunkitkm» indusoy; its use extendi u Internet addien «dtti addithuiil 
aoum/desdnitioapcMnQutkiben. Inotherv rdh a souroe end detdnatkm of 
dmcanbekfentifledeoonceMetoiorenl iddrmandapoitnunter 
knowneeaaoGket UDPalkmonepayiicaladdmstobetMQkendQm 
5 aeveial logical «ddieim. thus allowing mm ipedAo addmsiog wltUn a 

limltBd nuinto of phyilGal addieaea. 

UDP SA2Q2 adds a header to the mesnge. Tlie header oonrists of 
souioe/deitiaatlon porti, a IMlt leogdi field* and a almple check sum of the 
diia being aent. UDP SA202 then Ibrwaidi die data to die Bthernet htyer, 
10 SA204, 

If uagi^n stiened tfitt diit example illustates one embodlmem using 
TCPHP rrtansmU^ Control Pioinool/lnleraet Protocol). It is stressed that 
diem huertee SAIiVt and apfriicatlons SA102 aie not confined to 
commui^catiiigwhh one another using TCP/IP pfotDooU nor are they confined 
15 to communicating via Bthemet. In tet, it is not even requiitd that the 

communkatkm be vto a LAN. although diis is pmfemd. 

Bdiemet layer SA204 attaches an Edmet header to the packet and 
routes die packet over LAN SAIU to the destination Ethernet layer SA204. 
Ediemet layer SA204 at the destination removes the ethemet header 

20 Inlbrmation and provides die data to die UDP of byer SA2(Xl at die 

desdnadon. Here VDP SA2Q2 removes die UDP header infbrmadon and 
pnivides die message to CLOP SA104 at die desdnadon. Note, where a CUP 
SAIM Is not used at die desdnadon, dOs dirta is provided direcdy to die 
reoei^Qg applicadon SAI02. Also note diat in die case of some aerven, a 

25 ^nqilified CUP SA104 (referred to u SRVR SA206) U uaed in pirn of 

CLIPSA104. SRVRSA206doesnotprovideallofdiefunedonalityofCUP 
SA104. For exaaqde, SRVR SA206 does not check to see if a message 
received is a duplicate message. 
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Fig* 134badiasiamUluttritii^tbeooiifigufitioaafa|ka^ 
embodimem lem acrou LAN SA112. Referriog now cq Rg. 134, this pacta 
18 now denibed. LAN packet SA3(B inclndea mesaige dali SA304, 
Meaiage data SA304 ii the original data provided by tending application 

5 SAKS. 

Amp header SA306 is a header provided by CLIP SAl^^ CUF 
header SA306 contains infomation nffeiiary fisr CLIP SAICM to pevfbnn 
message and man^gemem functionality as described below. ThisfimetloaaU^ 
can include automatic retransmission of messages, cheddog for d up l icatio n 
10 of messages, and odier message fnanagemem-ietaied functions. UDP header 

SA308 is a user dat^gnun protocol header omsistiqg of soium/<tesdnation 
pons, a 16-bit lengdi field, and a single check sum of the data in die packet 
UDP header SA 308 klendfles die socket 10 which the packet shouU be se^ 

lEBB 802.3 header SA310 is the Ediernet header used to route pachtt 
15 SA3a2 moss Ethernet LAN SAl 12. 

The funcdmlity of CUF SA104 is now described at a hi^ levd. 
Fig. I3S is a data flow lUagraro illustrvtiftg tmnsnusmn of messages udqg 
CLIPSA104. Fig. 136 is a high-level opeiadonal flow diagram inustiattng 
the process followed 1^ CUP SAIM in handling messages. Referrii^ now 
20 10 Figs. lis. 136and 137. ifiplicadon SA102A (Fig. 13S) wishes to aend a 

request SB102 to application SA1QI2B. Fv example, application SA102A may 
be nmnii« in CMP BA 102. and may wish to send a GET CALLHANOUK 
RE(H)EST BA304 to BSRVR BA108. 

To send request SB1Q2. application SA102 utilitts CUF SA104. In 
25 a step SB2Q2, CUP 5A104 sends request SB1Q2 to applkatkm SA102B. 

Application SA102B may or may not have its own CUF SA104. depen£i« 
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oa the level of message maiutgemeiiC ftinctkmality required by application 
SAIOZB. 

In a step SB204, CUF SA 104 sets a timer SA402 (illustnted in Fig. 
137) to indicate the time ttm requeit SB102 wai sent Timer SA4Q2 U used 
S to establish a time-out* If a mpme SB104 is not received by the time the 

timeKnit period expires* CUF SA104 may send anodier request SBIOZ to 
SB1Q2B. 

If response SB104 is received before tim54wt period expirss (dedskm 
block SB206) CUP SA104 provides re^KHise SB104 to application SAIOIA. 
10 ThiaooeunintheiiepSB210. 

If, on the other baod, a response is not received before the dme-out 
period expires (decision block SB206), CUP SA104 determines whediN' it 
riKwM attempt to wsnA request SB102 again (whedier it should ittiy die 
request). This occurs In step SB20B. If die number of retries Is not 
IS exhausted, CUF SAt04 sends anoAer request SB102 to application SA102B. 

This occurs in a step SB214. At Ais time, CUP SA104 sets amMher timer 
SA402 in step SB204 and waits for die response to be received before die 
time-out period expires. 

If, on die odier hand, the number of retries allowed is exhausted In step 
20 SB208, CUP SAlOi determines whedier diere is anodier application SA102B 

to which requett SB102 can be sent. For example, if a CUF SA 104 in CMP 
BAIQ2 repeMdIy foils K> get a response to a GET CALLHANDLE 
REQUEST BAa04 foom a BSRVR BAIOS, diat CUP SA104 can detennine 
whedier anodier BSRVR BA108 can respond to die GET CALLHANDIE 
25 REQUEST BA304. 
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If no other application SA102B is available^ in a itep SB216 CUF 
SA104 nodfiei ^llcaiion SAIOZA, that an enw has ooeuiitd. 

If, on the other hand, another application SA1Q2B ]$ available, CUF 
SA104 beginB the procen again at step SB2Q2 by Kodiqg request SBIOZ to the 
other application SAtOlB. 

The described Heatures of utilizing timn ^MCl to determine a time- 
out, establishing a number of retries indicadng the ninriier of dmes that 
request SB1Q2 can be resent, and finding an aheraaiive server tiypliratinn 
SA1Q2B) an optioni tetures of CUF SAM, 

One embodbnem of CUF SA1(M is now described. Fig. 137 is a 
block diagram illustrating files and tabies used by CUF SA104 in one 
embodiment. 

Refienii^ now to Ftg, 137, CUF SA104 uses a timer SA4Q2« a teory 
coum SA40g, a duplicate detecdmi table SA412, an outstandb^ request list 
SA406, a oonfiguiation file SA404, a bufier pool SA414, and an Inoomhtg 
packet list SA410. In one embocttmem, the icny omtm SA406 Is nudmained 
in outstanding request list SA406, and die hihial nunter of retries d 
kept In cooQgufatkm file SA404. 

Each CUF SAt04 performs message managetnent fimcdoRS to one 
morepiooedures wtddnan^licatkmSAlOZA. CUF SAiOi is re^onAle 
for sending messages to and reodvii^ messages from otfwr applications 
SA1Q2D. Odter^»plteationsSAlQ2BmivhavedieirownCUFSA104,or 
may communicate whhoutusii^ a CUF SA104. Ap|dicatioa SA102 may be 
nttwoited widi other applications SA102B via a local area necwmk or a wide 
area networic, of they may commofucate via other comnmnicatkms means. 
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The prooeis by whkh CUF SA104 mdi a mesttge and itodvct a 
mess^ it now dtscrited. In tUs deacri|ykkMi, the menifB lent is cenned a 
request SB1Q2 wblle te memte received is teimed a response SB104. It 
shouid be WMBd diet CUP SA104 can sml ai^ type of messnge. and diat 
5 messege need not be a request However, aoocmUng to one embodirnBol, all 

messages tent are replied to using a response 90 the sending CUP SAiOi cin 
veriiy that the message has been received at the destination. 

Fig. IBgisablockdiagiam iUustmting a request being semSB102 and 
a reipoose received SB104 by a CUP Pig. 13g is sindlar to Fig. 135, 

10 however, in Fig. 13S,tfaeappHcadonaencUngre9iestSBi()2andlt8CUP are 

tenned a request!^ application SA102A and CUF SA104A. Similarly, the 
application receiving request SBKQ and sending a response SB104 Is labeled 
re%xiMBi« appllcatloo SA1Q2B and its associated CUP Is labeled SA104B. 
Please note that a CUP SA104B Is optional on the responding side. Pig. 369, 

IS which oomprlaeinga. l40andl41,UanopeiatkmBlflowdiagnaniHustnting 

the ptoceu by wMch CUP SAI04A sends and receives messages. IHg. 142, 
is an opeiational flow diiigmm illustnuihg what occurs when a response is 
leoeivBd by CUP SAI04. Again, dds discussion is made in terms of sending 
a requett SB102 and receiving a re^KMise SB104 in reply to request SB102. 

20 It should be noted again that request SB102 and response SBI04 are only one 

type of message dua could be sent and received by a CUP SA104. 

Referring now to Rgs. 138 and 139, in a step SB402, applications 
SA102 (requesdng application SA102A and le^MMiding application SAIOZB) 
inform their respective CUPs SA104A as to die messages they vrill be 
25 aoceptiqg. In tfiis manner, applications SAI02A can use CUP SA104A to 

effectively filler the messages that applications SAI02 receive. Requesting 
application SA 1Q2A for eumple, can inform CUF SA lOiA u to die certain 
types of messages that it is aooei^ng- If a message is received by CUF 
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SA104 and it is not <me of ttieie mem^e lypet, CUP SA104A tgnom or 
diacardi the memiSB. 

k should be noted that appUcatkmi SA102 are only requiied to 
complete itep S&4Q2 If dtey expect lequeia to be made of diem. It is not 
necessary for an application SA102 to inform CUP SA104 tfiat it will accept 
a response lo a request made 1^ that application SAi02. 

When requesting application SA10I2A wishes to send a request SB102 
to a reqxmdliv implication SAIOZB, ftquestlqg appUcttlon SAIOZA first 
Informs CUP SAi04A dat it wishes lo send a request SB1Q2. Tins oocors 

In a step SB404. 

j 

in a step S&406, CUP SA104A determines whidi route to send request 
SB102 to respondiqg tppUcation SAi02B. Tlito deiermlnatiQn is made iisii« 
information contained in configuration file SA4M. To maite this 
determination, CUP SA104A uses a cost foctor table and a ranee of dient 
addresses table contained in configuration file 5A404, The toA foctor table 
provides the cost to send request SB1Q2 lo reyondi n g applicatioo SA1Q2B 
over various routes. Uiing cost ftctor table, CUP SAlOiA can determine 
the most cost'^fCBctive route to use to send request SB1Q2. The range of 
client address tables specifies a range of aerven that can be used in sending 
request SB1Q2. 

In a preferred endxKlimem, die cost fKtor tsUe b a matrix of sourM 
and destinations. The tmeraection between cad) source and destination pair 
Is die cost far routing between tint source and destination. CUPSAltKAcan 
use die Inforniatioo in die cost tenr table to determine ttie cost between eadi 
sjuroe and destination pair and die total cost of a route made up of several 
source and destination pairs. 
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In a Stop SB408. CUP SAlfMA aves nqpM SB102 in outstanding 
lequest list SA406. Outmndii^ ie«|uest list SA406 U used to tnck a requ^ 
SB1Q2. WhNniespoi»lo«iequestSBia2isreodved, dwtm^ 
is deleted from out8tandii« request list SA40S. Htus, if a request SBt02 is 
found In outstandli« request list SA406, CUP 5A104A knows that no 
le^Nmse SBI04 hu been received for that request SB1Q2. 

In a step SB410« CUP SAlOiA sends request SB102 to the appropriate 
destination (to responding applicatkm SA102B). 

At die same time, in a step SB412, CUP SA 104A starts timer SA4Q2. 
As noted above, dmer SA4Q2 is used to establish a time-out period within 
which response SBIOi should be received. If mpatm SB104 to request 
SB1()2 is received before the tiroes period has eiplred (decdsicni block 
SB414), die operation condnues in a step SBSQ(2 Oilustnttd In Pig. 142). If, 
on the other hand, ivaponse SB104 to request SB102 Is not received within die 
dmenout period, CUP SAKHA may attempt a retry. In odier words. CUP 
SA104A may attempt to reaend request SB1Q2 to die desdnatkm. 

Before request SB102 is resem, CUP SAlOiA eximines die retry 
coom SA408 for diat requett SB102. This oocura in a step SB416. Ifdiere 
are rstiies left, CUP SA104A increments die reoy count SA408 for dut 
request SB1Q2 in a Aep SB417. CUP continues at step SB410 and resends 
request SB1Q2. 

If, on die odier hand, no retries are left in siep SB416. CUP SAlOiA 
determines whedier a new nnifee can be chosen over v^ich to snid request 
SB1Q2 to die desttnation. This occurs hi a step SB41 8. 

If a new route exists (decision block SB420), CUP SA I04A condnues 
at step SB410 and sends requett SB102 via die new route. If, however, no 
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new route exisis (dedskm block SB420)« CUF SA104A infonns wqauAng 
applfciuion SA1Q2A thit an error has occttned. This oocuis in stq» SB422. 
At this time, itquesci^g application SA102A may decide to itsend request 
SBIOZ. 

As mentioned above with icferenoe to step SB414, if a cesponae is 
received within tiie tinifrKWt period, die opentioo oontimies at step SRS02, 
IVtmifV now to Bg. 142 Jn step SB5Q(2, a received raponse SB104 b sioied 
in a buffer pool SA414. In one embodiment, buffer pool SA414 is maintained 
by a procedure Icernd which inftxrms CLIP SA104 when diere is a packet to 
be processed. 

In a stq) SBS04. CUF SAICMA matches die reoeM response SB104 
widi die requests SB102 In outstanding re(piestHstSA406. If re^ionae SB104 
oorreaponds tti a request SB 102 in outstandii^ request list SA406, dus request 
SB102 is deleted fkom outstamfing request list SA406 in a step SBS06. 

In a siq> SBSOB, CUF SA104A provkles re^mse SB104 toa|)plKation 
SA1Q2A. In one embodiment, dda step is aooomplisbBd by CUF SA104A 
informii« application SA1(12A duu response SBIM has been received and 
stored in buffer pool SA414. ApplicationSAlOZAdien retrieves die response 
SB104 fhmi buflbr pool SA414. 

Figs. 138. 140, and 142 discussed message handling in terms of a 
CUF SA104A sending a request SB102 and reoeiviiig a response SB104 in 
reply diereio. CUF SA104A u not limited to recriving only responses 
SB104. In tet, die above discusnon makes it obvkKudntCUFsSA104 can 
receive requests SB102 from odier applications SA1Q2 or re^mnses SB104 
from odier applications SA102. Himl^ when a message is received by a 
CUF SA104, it firat diecks to determine whedier it is a regionse SB104 to an 
outstanding request SB102, or whedier it is a request SB102 from another 
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^ipltcaiionSAlOZ. If the mesnte received ii a iequestSB102.CUFSAl04 
infomu appliouloit SA1Q2 dnt a request SB1Q2 hu been received. CUP 
SAlOi makes request S&1Q2 available to a|iplication SA1Q2. 

In one embodinem, request SB1Q2 is stored in buffer pool SA414, and 
application SA102 is lutified diat requeA SBIQZ has been received If 
receiving applicatioii SAI02 has legistmd for requests fipom the aen^ng 
i^iplication SA102. InfBrmatkin about die request SB1Q2 (e.g. die 
idendficMion of die sending applicatitm SAI02, etc.) is stored in incoming 
pvfcetiistSMlO. 

A more detailed discussion of die procedure followed by a CLEF 
SAiOi when it leoeives a request SB102 is now desoibed. Fig. 143 is an 
opeiadoml flow diagram illintnttittg die process diat occurs when a CUP 
SA 104 receives a request $BI02. 

Referring now to Fig. 143, in a step SB60Z, CUP SA104 receives a 
request SB102. 

In a step SB604, CUP SA104 checks lo see if die lecetved request 
SBIOZ is a request dnt was previously sent and received by CUP SA104. In 
one embodtmem, CUP SAI04 checks a retry count in a header of die 
message. If die retry coum is wo (0), this indteaies that die request SBia2 
received is being sem from its originating application SA 102 (or tbe first time. 

In diis case, CUP SAI04 savn request SB102 in duplicate detocdon 
table SA4I2. This occurs in a step SB606. In one embodtmem, request 
SBIQ2 is saved in duplicate detection table SA4I2 akwg with die time diat it 
was received. This enables CUP SAI0<1 to delete messsgesdmt have reached 
acertun age. 
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In a itep SB608, CUF SA104 provides lequeit SB1Q2 to ^kation 
SA1Q2B. In(meeinbodiroem,CUFSA104infom 
requett SB102 is stored in buffer pool SA414 and qiplicatioD SAtOZB 
retrieve! request SB1Q2. 

If, on die odier hand, the letiy count insiq> SB604 is greater than aro 
(0), this imticales diat the request 58102 has been previously sem and tto 
aretiy. In dils case, CUF SA104diecks duplicate deiecdaatil)leSA412io 
see whedier CUP SA104 actually received this ptrtteular request 58102 
before. This occurs in a step S8610. This check is useful because request 
58102 may be a retry for several reasons. One reason may be because 
request 58102 was never received by CUF SA104 «^ it wu sm die first 
timedueiDatnuismissionerror, In this case, no entry for diat request SB1Q2 
will appear in duplicaie detection table SA4I2, and CUFSA104 treats request 
SB102 as a new message. 

If die retried request 58102 is a duplicate (dedskm block 58612), in 
a step 58614, CUF SA104 eidier resends response 58104 or sends a hold 
response SD104 (illustrsied in FIG. 146). If. on die odier hand, die retried 
request 58102 is not a duplicate, CUF 5A104 saves request 58102 in 
diq>licale detection tsble 5A412 in step 58606 and provides request SB1Q2 to 
appHcation SAIQ2B in step 58605. 

The above discussion on the client interfooe describes how CUFs 
5AI04 can be used to manage and handle tnessagetnlfic Adcfitional features 
can be provided by CUFs 5A104, as are now described. These features can 
inclucte duplicate detection (intraduoed sftwve widi reference to Fig. 143) and 
a request hold fieature. 

The feature of duplicate detection is now described in detail. Fig. 144 
is a data flow diagram illustrating messages sent between requesting 
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applicatton SA 102A and icaponding application SA1Q2B unng CUPs SA104. 
Fig. 145 is a detailed qieradcuial flow diagiam ilhutntiog die prooeii by 
which a CUP SA104B delects the presence of a dufriicaie lequett SB102 and 
prevents responding applicatltm SA1Q2B tnm having to respond more than 
dice* 

It is inoportant to note that in mier for this di^aicaie detection ftatme 
to openie, lespondii^ application SAlQCffl must have an asi ocia tB d CUF 
SA104B. Ahhough« as mentioned above, re^ionding applications SAIOZB 
need not have a CUF SA104 to respond to requests, having a CUP SA104 
allows this thvplkate detection feature to be Implemented widi leferenoe to dut 
responding applicttkm SA1G2B. 

One example of where duplicate detection is not necessary is in die 
case of call process dandMse and NCP ABI04. in diis scenario, NCP AB104 
is analagous to requesting appiicatton SA102A. Ddbit card database KA272 
is analcgcws to responding application SA1Q2B. (SeeFtg. 118.) Inthiscsse, 
when NCP BA104 sends a debit card ddlar amount update to debit card 
database 1CA272, debit card database KA272 does not care whether it gets 
updated twice (in odier words, whether die same information is written into 
die dattbaae). Thus, in this scenario, having du|rficate detection is not needed. 

Referrii^ now to Fig. 144 and 145, die di^icate dmoion will now 
be described in detail. In a step SC202, requesting application 5A1Q2A tells 
CUP SA104A to send a request SB IQ2. This Is die same as die process dwt 
occurred in step SB404 of Fig. 140. 

In a Step SC204, CUF SA104A sends request SBt02 to destination 
CUF SAI04B. As described above, CUF SA104A may set a timer SA4Q2 
when request SBIQ2 is sent. In step SC206, CUF SAI04B receives request 
SB1Q2. CLIP SAI04B first determines dul die message received is a request 
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SB1Q2 and ten determines whether the requeit U a duplicaie request This 
oocuiB in step SC208. The manner by which CUF SA104B deteimines 
whether request SBIQS is a duplicate is iiiustrated in Fig. 143 with referen ce 
10 steps SB602 thiough SB60B. 

if rtiis is not a dufriicale request SBIQ2 (in other words, if this is the 
nm time CUF SA104B received diis request SB1Q2), CUF SAKMB provides 
request SB1Q2 to reqioiiding application SAI02B. This occurs in a step 
SC210. Responding application SA102B prepares a re^XMueSBlCM to request 
SBI02 and sends nqmse SBI04 lo CUP SA104B. In a step Sai2» 
legKMiding application SAIQ2B tells CUF SA104B to send response SB104. 

In a step SC214, CUF SAKMB sends response SBlOi. In Fig. 144, 
this is illustmed as SB104A. Acooiding to this scenario, however, response 
SB104A does not make it to CUF SA104A that origlnaOy sem request SBia2. 
Thereffore, when die dme-out period expires at CUF SAKMA, CLIF SA104A 
will again send request SBI02 to destination CUF SAKMB in step SC204. 
This is illustnued by request SBIOZB. 

CUFSA104Breceivcsreque8lSBia2BinsttpSC206. lnstepSC208, 
CUF SAKMB determines wh^her received request SB1Q2B is a duplicate 
request Because it is a duplicaie request, CUF SAKMB bypasses step SC210 
and does not inform responding appticatton SA1Q2B of the request This 
saves respondng applicatioo SA1Q2B from haviiig to respond agpln do a 
seocmd request InAead, CUF SAKMB prooeeib to step SC2 14 and resents 
reqponse SBKM. This is illustrated as SB104B in Fig. 144. This time, in step 
SC2I6. CUF SAKMA receives response SBKMB within the timeout period. 
CUF SAKMA provides response SBKMB to requesting application SAKQA. 

One key idvantikge gained by duplicate detection is dot it protects the 
integrity of die data and die operation of call processing system AB 102 by not 
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alkiwing requests SB1Q2 to be piooesied more thui onoc. AddidonUy, 
duplkaiB detection saves reipondiiig application SAia2B fiom having to 
respond Id tile same requett SB 102 tv^ This sidft of nonagement overhead 
from responding application SAIQZB to CUF SA104B saves valuable time in 
responding application SA102B. The management oveihead aasodaied with 
retryii« die request SB1Q2 Is also MfleA to CLIP SA104A, thus alteviatiog 
requesting application SA102A of the buiden. 

Anodier feature provided by CUF SA 104 is die abilhy to Increase die 
tiine Intennl between r^esifiespondittgap|rtlcatlooSAl02B IS busy. This 
feature is now desolbed. Fig, 146 is a data flow diagram illuatiating die 
manner in which one CLIF SA104B can Increase die dme interval between 
retries of a second CUF SA104A. Pig. 147 to a detailed operational flow 
diagram IHustradng die process by which a first CUP SA104B increases die 
time interval between retries of a second CUF SA104A. 

Referrii^ now to Figs. 146 and 147, In a step SD2Q2, requesting 
application SA1Q2A telU CUF SA104A to send a request SB102. 

In a step SD204. CUF SA104A sends request SB1Q2 to destination 
CUFSA104B. CUFSA104BrBoeivesreque8tSB102in8tepSD206. Attiils 
time. CUF SA104B can perform duplicate detection and/or any odier desired 
functions of messnge handling. 

In a step SD2a8. CUP SA104B provides request SBIQ2 to application 
SAIOZB. However, in diis scenario, applicadcm SA102B is busy and is 
responding to requests SB 102 slower dian to expected. This is illustrated in 
block SD2I0. 

Because responding application SA102B to opersting slower dian 
expecred, die time-out period in CUF SAI04A expires before a response 
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SB104 is meived. Thus, in itq> SD212, OiP SA104A mends lequesi 
SB102. This ift Ulustmted by mferme nuntber SBIQZB in Fig. 146. 

CUP SAlOiB icoeives teoond leq^ SB102B, emninei the retry 
count, and determines that recpiest SBlti2B wis previouflly rmtved and 
foiwaided to respondiqg application SAIOZB. Becatoetaponding application 
SAKSB sinady teccivBd request SB1()2, CUF protects ic^nndiQg application 
SA1Q2B from leoeiviog it again. Therefore, In a sttp SD216, CUP SA104B 
sends a lequest hold message SD104 to CUP SA104A. Request hold message 
SDlOi indicaiBS to CUP SAICMA that reqiondii« appUcadoo SAIQ2B 
reodved request SBtOZ (and request SB102B). and that a re^mae is 
fbrthoomlqg In due time. In one entediment, CUP SAKMA responds lo 
request hold message SD104 by Increasing die dmo^ time set by timer 
SMttl, Thus, CUP SA104A Increases die time benrem retries. 

An additional feature provided by CUP SA104 is tint it can provide 
automatic retransmission of a request SB1Q2 to aootfier application SA1Q2 If 
requests SB1Q2 to die first spplicatian SAlOa haire been unanswered Thus, 
if a primary q)|rtication SAIOZ appears bu^ or miasiqg, CUP SA104 can 
automatically transmit die request SB1Q2 to a secondary application diat can 
receive and tffocess request SB102. Adcfitiooally, if die primary spplication 
SA102 again becomes available, CUP SAlOi antomatkally reroutes die 
requests SB1Q2 to diat primary application onoe ^pin. Multiple secondary 
applications SA1Q2 can be designated as badc-ups to dK primary. Thesecan 
be prkiritiad to estidilish an order m which CUP SA104 tries to send 
SB102 to diem. 

This prioritiation can be aooon^lished by referring to a piioriQr list 
of multiple applications SAIOZ, each perfbnnii« die same firoctioD, and a 
route able indlcatii« to which application SA1(I2 it would be most efficiem 
to route request SB102. Thus, if diere are several applications SA102 duit 
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perfonn the mat function (for example, leveial ipplicatkmi SAI02 that can 
reipond to a GET CALLHANDLB REQUEST BA304), CUP SA1(M can 
determine which of those leveial apptteatkms SA102 shouU be uied as the 
primary souioe, which should be secondaiy, and so on down the line, 
dependli^ upon ifae number of ^icatkms SA1Q2 available. 

The manner in which CUP SAICM prioritiaes applications SA1Q2 to 
which a vequest SBt02 is sett is now described. Rg. 148 is a dataflow 
diagiam illustniliQg die manner in which CLIP SA104 sends messages (for 
example, itquests 5B102) 10 an spplication SA 102 with die highest priori 
10 Ftg. 149 is an opemtimd flow diagnmiilustiatiqg die process by which CU^ 

SA104 sends messagos (for example, requests SB102) tt> an ^iplicatlcm SA102 
having die Idghest priority. 

Referring now to Figs. 148 and 149, when CUP SA104 receives a 
tequest to send a message to anodier appllcadoo SA1Q2, CUP SA104 first 

IS checks a priority list in configuration file SA404 to determine the pitferred 

application SA102 to which request SB102 should be sem and die order of 
priority of applications SA1Q2 to which request SB1Q2 may be sent. This 
occura in a Mqi SP202. In one embodiment, configuiadon file SA404 Is 
examined at application stan-up and its information, including priority 

20 information, is siored in a series of tables. 

In a step SP204. CUP SAi04 sends request SB1Q2 to Che applicadon 
SA102 having Uie highest priority. Tliis is illustiaied in Pig. 148 as 
iqiplicadon SA1Q2C. 

When CLIP SA104 does not get a response SB104 widiin die 
25 designated dme-outperiod, CUP SA104resends request SBI02. Because, in 

diis scenario, die higher priwiiy applicad<m SA1Q2C is unavailable, die 
original request SB1Q2 and all dw subsequent retries of request SBIOZ lemain 
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unanswered. Therefore, CUP SA1Q4 ocmdniiei lo reiend request SB102 undl 
ttiemimber of retries pemitted it exhautted in t step SP2^ This Is fiiitlier 
illuitiBied in and described widi reference to Fig. 140 In steps SB41(KSB417. 

CUF SAI04 upifaues its route tables to no ku^ tew ^ipUcatkm 
5 SA102C as the higher priority application because this application SAIQSC la 

no loQger available. Thus, all aubsequeot retpiests SB102 will be routed to a 
lower priori^ application SAIOZD undl higher prioriQr application SA102C 
is again available. 

In a step SF208, CLIFSA104 dMrmines die applicatian SA102 next 
10 on the priority list (IHiutritBd in Fig. 148 as applkatkm SAIOZD). CUF 

SA104 sends request SB102 (and subseipiem lecpiests SB102) to apptication 
SA1Q2D. This step Is lllustnted and discussed widi reference lo step SB418 
in Fig. 140. 

When request SB102 is re*niuted to die lower priority application 
IS SA1Q2D, CUF also SA104 sends a check message to the controlling 

application (for example, die server controller) to determine if it is die entire 
server or juit die application SA102C dat is not responfiqg. The frequency 
of CHECK MESSAGE SF102 can further be limited by a set time imerval. 

To enable CUF SA104 lo determhie when die higher prioriiy 
20 application SA102C again becomes avaihMe. CUP SA104 senda a CHECK 

MESSAGE SFI02 to die h*i^ priori^ applkadon SA1Q2C. CUF SA104 
is expecdng a CHECK MESSAGE RESFWSE SF104 when applicadon 
SA102C Is agun available. CUF SA104 can omdnue to send CHECK 
MESSAGE SF102 to applicadon SAIOZC at periodic inKrvals until a 
25 CHECKMESSAG£RESFO?«CTSP104isrecdved. If application SA1Q2C 

is available when it Is sent a CHECK MESSAGE SF102, it sends CHECK 
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MESSAGE RESPONSE SP104 to CLIP SA104. Thii is illustnled in step 
SP212. 

In a step SP214. when CHECK MESSAGE RESFOfBE SF104 is 
received, CUP SA104 knows ttat SA1Q2C is igiin available and i^dates its 
5 configufatkm file SA4(M to again show application SA102C as the higher 

priority application. From this point on, new message (fo example, requests 
SB102) will be sent to application SA102C, and the operation continues at step 
SF204. 

iM DBF 

10 One problem teed by developen of convemional call piooessiQg 

sy^ems Is that of devdoplog call processing software diat is easily 
roidotaloable and highly reoonfigunbie. Anothtf problem is that of aeating 
a call processing system cspable of providing subscriber-uniqiie features and 
capabilities. As the ramiber of subscribers to die omventkmal call processing 

IS system increases, it becomes incra^ngly diffteidt to provide hi^ly 

maintainable and reoonfigunible code to handle a wkle varied of custom 
and/or standard features using conventional software techniques. 

In many oonvcttdonal systems, the call processing software is coded in 
such a way tittt when changes are to be made to the sytiem, entire sections of 
20 code have to be rewritten and recompiled. Thiscvibeadme-oonsumii^task 

and requires that die platforms on wluch the code is ronning be brought to a 
non-opereti<mal status while the new software is iosded. 

The inventors have developed a way to provide a wide amy of 
subscriber-unique and standard call processing ficamres white eliminating die 
25 need to recompile laige portions of operedonal software. According to die 

present invention, the call processing opersdons are driven primarily by data 
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reoofdi, known u DBF recoids. Call prooeuiiv system AB102 uses DBF 
records in conjunction with aJ) piooesaes to pravide lubicriber-uniqiK and 
standard call processing features. A call processes is staffed when a new call 
enters call processing j^stem AB102 The call process access one or more 

5 data fields in a DBF record diat Indicate how die callis lo be pnxxssed. 

Thus, DBF records can be used to dictate certain subscriber-unique features 
and g^ric features as well. When cttangesaie to be made to call processing 
system AB102, die ta^o^ of these chsi^ can be made by updadng die 
data fields found in die DBF reconb. Thus, roost changes to call prooessuig 

10 system ABKXZ do not reqiure operadonal software to be moififled, recomi^, 

and re-loaded. 

The manner in which call processing iiystem ABICQ uses DBF records 
to process calls is now described. Fig. ISO is a Ugh-level blade diagram 
illusoating die nuumer hi which DBF records are used by call processing 

IS system ABIOZ to process calls. Fig. ISl is an operatioml flow diagram 

illustrsdng die manner m which call processing AB1Q2 uses DBF records and 
processes to handte calls. Referring now to Figs. ISO ami ISU in a sep 
TA202. a call is received \jy call processing AB102. As described ibowe in 
dw Networic Control Processor Section of diis document, call data AA144 is 

20 routed to NCP AB104 and call audio AAl^ te touted to matrix swhch 

ABI06. For operuw^^sted cslls, call audio AA142 is dien routed to an 
opemtor console AB108 to provide operstor assistanoe. 

In a step TA206, NCP AB104 identifies die call and die 9pe of call 
being placed. The manner in whidi NCP AB104 procesKs die call is fidly 
25 described in die NCP Section of diis documem. 

lnastepTA2lO,NCP sends operator oomrol dtfa AB124 to operator 
console AB108. Operstcnr control dam AB124 tndudes information required 
by operator console AB108 to process die call. This information includes a 
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bue prooen number, a DBF ceoofd number, and other call information luch 
as ANI. called pai^ nundier, subscriber idendflcadon, etc. At this time, 
opentOT console AB108 can begin piocessing die call. 

In a step TA2 14, operaMM^ console AB108 staits a base praceu TA 102. 
The base pnxsess TA1Q2 started is Am base prooeu Identified by the base 
piooeu number flat was sent by NCP AB104 widi operalor omtrol data 
ABi24. Base process TA1Q2 is a process tempfaoe duu oontains die basic 
stqndiat are to be followed by operator console AB108 in processing die call. 
Base process TA102 Is coded feo look for certain i^eces of informadon within 
a DBF leoord TA104. Base process TA102 uses this informttlon to process 
die call. This Informadon can dictate dttt base process TAIOZ Stan otfier 
processes TA106, wait for user AA106 input, or wait for operator 
i n structions. 

In a step TA2 1 8. base process TA 102 retrieves die DBF record TA 104 
as specified by die DBF record number diat was sem widi operator control 
data AB124. 

In a step TA222, base process TA102 uses die information in DBF 
rccmd TA104 to proceu die calL This process is described in more detail 
below with reference to Ftgs. 1S2 and 153. 

In one embodtmerU, when base process TAKQ has completed all of iu 
call prooessirtg operations, it starts a finiA process TA108 and sends a DBF 
record mxabtr idendfying a DBF record TAIIO dial finish process TA108 will 
use in finishing the call prooessirig. The fldsh prooesa TA108 is anodier 
process duu is designed to look for specific data tags TBI04 diat describe how 
to finish die call process. For example, finish process TA108 may look for 
a specific tag TBi04. This tag may point to a record dot displays keys on the 
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operator iciecn for the operator to pren to oomplelB the call , or that diiphyi 
(or plays in the case of t VRU AB134) a cMtng script 

In a step TA230, finish process TAIM darts complete call process 
TA112. Complete call process TAU2 compleies the call ptaoed by user 
AA106. 

The stnicture of DEP records TA104 (and TAUO in the case of a 
finish proceu TA108) is now mote fully described. Fig. 152 is a diagrun 
illustnuiag the stnicture of a DBF record TAlOi in one embodiment DBF 
record TA104 includes a DBF record number TB102. DBF record nuinber 
TB1(S uniqudy idemifles each DBF record TAlOi* DBF record nunter 
TAia2 is sent to operator console AB108 with upentor control data AB124. 
NCP AB104 deteimines which DBF record number TB1Q2 to provide to 
opeiatof console AB108 usiog call data AB144 during die CALL ID LOOK- 
UP BA306. DiffiMtm DBF records TA104 may be chosen and idendfied 
based on dw type of call dot is placed, the particutar subscrftier AA114 or 
odier call information. Thus, die operstitm performed by base process TA1Q2 
can be custom tailored based on call data AA144 and by the use of different 
DEFitooidsTAKM. 

The fields widiin DBF reomi TAt04 include a number TB104, a 
lengdi ftdd TB106* and a data field TB108. Tig nund)er TB104 it an 
tdemifter diat base process TA1Q2 uses to find spedfk data TBI 10 widiin 
DBF record TAIM. Leivh fteU TB106 specifics die lengdi of data field 
TB108. Data field TB108 contains data TBllO used in processing die call. 
Data TBttO can be die actual tiaia used lo process die call, or cui be a 
reference to data in anodier data file, data tMt, or dttabase. 
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Depending on die putkular DBF nooid TA104, any number of fields, 
which oon4>ri8e tag numbers TB104, leqgih fidda TB106 and daia fteldi 
TB108, can be provided in a DBF reooid TA104. 

Base process ThVn is coded (o look for certain tag numbers TBUM 
widiin DBF reconiTAl04 at cenain times. For example, base process TA102 
be coded to look for tag nunter I, then tag number 2, dien tag 
number 3. Tag number 1 may be a tag Idendfyiqg a greeting script to be 
pl^ by an airtomated VRU AB134, or read by an operator at a manual 
opentor console AB132. In this caae, base process TA1Q2 Ma in DBF 
teooid TA104 for tag number I and reads data TBllO in data field TB108 
assodated widi tag number 1. In die case of a greeting script, data TBI 10 
will poim to die script to beplayed, read, or syndiBsiaed to user AA 106. The 
script can be customlnd to a pardcnlar customer AAUO in a number of 
different ways. One way is for NCP AB104 to provide customer AAilO 
identification to operator console AB108 widi operator control data AB124. 
Operator console ABI08 would then use dits idemification information in 
conjunction widi dam TBllO in data field TBlOSassodaied widi tag number 1 
to read die carrier-unique greeting script found in a database. For example, 
operator console AB108 will go to die database to retrieve die script identified 
by data TBUO and die carrier idemification. Opcratin' console ABI08 dien 
plays diis script to user AA 106. In die case of a automated VRU AB134, die 
script pteyed can tie voice symhesiied or pkyed from a recording. In the case 
of a manual operatcH' console ABIS2, die script is displayed In text format on 
a screen and die human operuor reads die script to die user AA106. For 
example, die script may say *Wdcome to XYZ C6mpany*s voice mail 
system,* or Thank you for using XYZ Long Distance Company. Please 
enter your calling card number now." 

In addition to playing scripts, base process TA 102 can be coded to find 
tags to perform numerous odier functions, ftir example, base process TA 102 
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can be coded co perfBnn vatkbuon of dam metvtd. For example, liaae 
process TA102 may be coded lo itcrievc anodier tag that idemtfies that die 
called luuhber teuld be validaied to verify diat die called mnnlier ii die 
correct number of digits (for example, 10 digiu). In this case, when baae 

5 proceu reads die data TBIlO assoclaied widi diat tag mmdier, bue pfooets 

TA102 may start an addidomd process TAI06 diat performs die validation. 
This results in a valklatioii ttqiiest GA122 bdng sem to die validation Qfsie^ 
AG102. Once taaae process TA102 starts die additional process TA106. u 
doesn^t necessarily have to wait fat die additioial proem TA106 to be 

10 compleiBd beftnc moving on to the next tag. 

As ancidier example, bate process TA1Q2 may be coded to retrieve 
anodier tag t!iat requires dot die calling card number be validaKd diroogh 
validation system AB1Q2 as described in die Validatioo System Section of diis 
document in diis case, data field TB108 associtied widi diat tag will dtrect 
15 base process TA102(o send a requett to validation system AGIQZ 10 validate 

die calling card mtnter. BaK process TA10(2 continues to read tags and 
perform die operations dictaied by die 0^ Thus, chaqges to call procestinii 
system Afil02 can be made by rBdefimng die dtta TBllO in dtta fields 
TB108. 

20 Base proceuTAlQl need not look for every tag number TBlOi within 

a DEF record TAI04. It may« instead, only be coded to search for certain tag 
numbers TBIOi widi a DEF record TA104. 

When prooessini die call, base process TA102 is abo capable of 
acceptii^ and respondir^ lo inputs from osn* AA106. For example, data 
25 TBllO may also include strifes which base process TA 102 uses to match 

against user input For example, base process TAI02 may be programmed to 
retrieve TB104 diat define data fields TB108 10 match user iiyw strings 
*2lf.* *3f.' For each cfdiese user inpm sequences, data TBllO umcpiely 
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defines a process TA106 to be started or another base process TA 102 to be 
started. For example, one particular DEF record TM04 may define that 
when a user dials It, a second base process TAI02 should be started. Data 
TBUO identifies this base process with a base process number and can also 
identify a specific DEF record TA104 for the new base process TA 1 02 to use. 
For example, a user dialing \0 may indicate that the user wi^ies to access a 
speed-dial feature. In this case, data TBI 10 and DEF record TAi04 will tell 
base process TA 102 to stan a speed-dial process when this striitg is detected. 

To recapitulate, processes TA 102, TA 106, perform operations the can 
be done in a number of different manners. The way in which the operation 
is performed for a specific call is dictated by the data TB220 pointed to by the 
tags TB 1 04 referenced. As the process TA 1 02 , T A 106 performs an operation , 
it may conte to a point where data TBI 10 from die DEF record TA104 is 
required. At this point, the tag TB 104 is referenced and its associated data 
TBI )0 retrieved. 

Consider the base process TA 102 as an example. A base process 
TA'02 is typtcailly designed to collect information from a user AAi06, 
validate the informaion collected, and pursue a course of action based on the 
information collected and the results of the validation. The general framework 
for completing these operations is coded in the base process TA 102: it must 
prompt the user for information, validate thr information, and follow a course 
of action. The data TBI 10 retrieved usii^ tags TBI04 provides the specific 
actioTiS to be followed by the process TA102. These can include, but aie not 
limited to: the manner in which the user is prompted* die order in which 
information is collected, the manner in which infbnraation is validated, the 
number of additional chances a user A A 106 is given after a failed validation, 
the action to take in die event the number of additional chances is echatisted, 
the amount of time to wait for input, the action to take if the time-out period 
expires, and a large number of other parameters. 
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Thus, the dtia TBllO found in DEF leoonls TA104 dictau how die 
call is 10 be processed by base process TA102* New featuies can be added, 
r xisdng featuies changed or deleted, and features customind for ipedfic users 
by updating one or more DEF records TA104. Thus, opeiatipnal code does 
5 not have to be modified and recompiled to implemem these types of changes. 

To minimiie the amount of duplicatkm of da^a TBllO, DEF reooids 
can be defined at various levels. Fsg. 153 is a diagram ilhistntti^ how 
differem levels of records TA 104 can be used to opdmiad data storage. 

Referrii^nowtoFig. 1S3. a generic DEF record TB2QZinchides data 
10 TBI 10 diatiscommon to all subscribers AAl 14. A group DEF record TB204 

can contain data TBllO dut is unique to a customer AAUO. Because diis 
data TBI 10 Is unique to a customer AA 110. it is not comalned in generic DEF 
record TB202. If a particular coslomer AAUO has m unique feature diat is 
differem fhrni odier carriers AAl 10, data TBllO fbr diat fbtmre is found in 
IS groq) Dl^ icoord TB204. 

Specific DEF record TB206 defines data TBllO diat is specific to a 
user AA106. If a user AA106 subscniies lo fieatures diat are unique fhmi 
other users AA106, <teta TBI 10 fbr diose features will be oontainBd in specific 
DEF record TB206. 

20 In search for data TBilO using tag numbers TB104, base process 

TA102 will first start in specific DEF rec(mlTB206. If tag number TB104 
is not found in specific DEF record TB206, base process TAIOZ dien searches 
group DEF record TB204. If tag number TB104 is not found in group DEF 
record TB204, base process TAIOZ dien goes to generic DEF record TB2aQ 

25 to find diat tag nunter TB104. Thus, if a user AA106 has a unique fcamre, 

or diat user's call is to be handled uniquely, the data TBllO instrucdng base 
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process TA1Q2 on how to handle thit call will be found in specific DEF 
record TB206 and used. 

A DEF record manager u a set of fuivtions calls used lo numage DEF 
recoids read by the applkatkm (for example, die apmm console ABIOS). 
The DEF Rcofd manager associates a DEF teooid widi a particular call 
process (base process TA1Q2). The allows die application to search for any 
tag TB104 in die system or tags TB104 widiln a particular DEF record 
TAUM. This is done so ttiat some tags TB104 may be accessed by any 
piooess TA102, TA106 dat may lequire it while odier tags TB104 can be 
lestricied only to die process TA1Q2, TA106 reading die DBF record TA104 
containing die tag TB104. 

I2J Optrmktr Smkn 

Call procesMi^ system AB102 can be used to provide operator services 
to subscribers AA114A. Call procesung system AB102 can provide opmtor 
assisted calling to origlnadng users AA106A who subscribe to a prooesnng 
system AB102. and to customers AAIIO. Customers AAUO may in turn 
ofiiBrdteseopaator services lodieir subscribing users AA 106. Asdiscussed 
previously in diis document, one feanire of call procesring AB1Q2 is d»t it 
can offer customer AAllO uidque ami iner AA106 unique customizable 
services. A high level scenario descrfbiiQ die manner in which operator 
services are provided by call processii^ system AB1Q2 is now presented. Fig. 
154, which comprises Pigs. 15S, 156, 157, and 1S8« is an opersdonal flow 
diagram illustratii^ die high level operator services scenario. Reforriognow 
to Fig. 155, In a step YAI04, call processing system AB102 receives a call 
requiring operator assistance. In a step YA108, call data AA144 associated 
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withtliecdl is routed CO NCPAB104. Callatidio AA142ofthecall israuled 
to matrix switch AB105. 

In a step YAl 12, NCP Afil04 recdves call data AA 144 for the call. 
NCP AB104 d^ermines the type of call bdog plaoed and die call prooeasiog 
lequired baaed on call data AA144. in one embodimem, this is aooompllshed 
by NCP AB1(M perfbrmiiv database look-ups udng call dala AA144 to seaich 
for data icoofds. In dils embodimem, die data reoonis indicate die 9pe of 
prooes^ng and operator services required to handle the call. An example 0! 
this Is where CMP BA102 retrieves call parameten BA308 from a database 
served by DBS BA104 and is discussed in the NCP Section of this document 
with reference to Figs. 10, 12, and 14. Also, NCP AB104 determines die 
opdmal routhig of die call. 

In a step YAl 16, NCP ABIM sends die roudug informadon to matrix 
switch AB106. Because tfiis is an apemtor*asslsied call, as determined by 
NCP AB104 in step YAl 12, the call routing inforrottion includes instnicdtms 
from matrix switch AB106 r^ardiog which operator console AB108 should 
receive call audio AA142 for die call. Thus, call audio AA142 can be nmiBd 
to die proper opentor console ABIM. It should be noted diat dependiqg on 
the type of operator assistance required, die opeotor omsole ABI08 lo which 
die call is routed can be a voice response unh AB134, a manual opecstor 
console AB132, or a customer service console AB136. In response to diis 
routiqg information, matrix switch AB106 routes dm call to die designated 
operator console AB108. Because NCP AB104 U comrollii« die call data 
AB144, and d» operator console AB108 oily die call audio AB142 
portion of die call from matrix switch AB106, opoaior conacde ABIOB is 
treated as any odier destination. Therefore, die specified operator console 
AB108 can be created just like any odttr temduadqg poim of matrix switch 
AB106. Tradidonally, such treatment was limtaed only to otfier switches and 
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qmial ports were required on the conventional matrix switch to interface to 
the operator consoles. 

In a step YAi20, NCP AD104 sends operator control data AB124 to 
the specified operator console AB108. Operator control data AB124 can 

5 include call ID information tiat indicates the type of call and the type of 

processing required to handle the call. Because call processing system AB 102 
is highly data driven, the type of call processing required for a call type can 
be customized for a specific originating user AA106A or customer AAllO. 
Changes to the way in whtdi a particular call is processed can be 

10 accomplished simply by changing the data in the data records retrieved by 

NCP AB104 when determining the call procesnng requirements. 

Operator control data AB 124 tells the specified operator console AB 108 
that it is receiving a call and how the call should be processed. 

Depending on the type of call being placed, the call can be handled by 
IS either a manual operator console AB132 or a voice response unit AB134. For 

calls requiring a human operator, a manual operator console AB 132 is desired. 
It should be noted that users AA106A or customers AAllO nmy specify 
whether automated call handling is acceptable at a VRU AB134 or whether 
they prefer that their calls are always handled by a human operator at a 
20 manual operator console AB 132. in one embodiment, this is controlled by call 

parameters BA308 and can easily be changed by changing the data found in 
the data records retrieved for one or more originating users AA106A or 
customers AAllO. 

If the call requires a manual operator console ABI32, die operation 
25 continues in a step YA304 as illustrated in Fig. 1S7. On the other hand, if the 

call can be handled using a VRU AB134, the operation continues in a step 
YA204 as illustrated in Fig. 1S6. The manner in which the call is set up 
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mini an tutomtled voice ittponse unit AB134 it now dcicfflied wUh 
leferenoe to Fig. 156. Refeniqg now to Fig. 196, in a itep YA3(M, die 
qiedfled VRU AB134 lequesu information ftom originating uier AAlOfiA. 
The lequect can be a request for the number thit originating luer AA106A 
widiei to call, the fieanife the originating uer AA106A wlAet lo aooett, 
calling card or credit caid information, or odier informadcm required •□ 
complete die call. The oider in which voice responre unit ABI34 requests diis 
call information can be customittd for each carrier AAIIO or for each 
individual user AA106A. The customiatioa can be based on caU paruneters 
BA30B and/m* die manner in which DBF reooids are implemented for each 
originatii^ user AA106A or customer AAIIO. KF reooidi are oompleiely 
described in the DEP aection of this document. 

If orighiadng user AA106A is placing a calling cafd, ddnt card, or 
credit card call, automated voice response unit AB134 may send diis bUUng 
informadon 10 an extenod validation t^ystem AG 102 so diat It may be valid^ 
externally In one embodiment This occurs in a step YA208. Inalteraadve 
endiodimeitts, validation of billing informadon is performed imemal to call 
processing syAem AB1Q2. 

In a step YA212, if a teraiinadng (called) number is entered, diat 
number is validated to verify dial it is a valid mmitaer. In one embo^Qmem, 
diis is aoocmiplished by using an internal vilidadon system to determine 
whedier It is a valid number. Odiervalidadon checks can include a check id 
see dat die number amialns die correct number of digits, that is made to a 
geogn^rtiic area as alkmed by die customer AAllO, has a valid area code, 
and odier like valkfattion information. 

In a step YA216, fraud detecdtm and prevendon system AGl 12 can be 
used in rnie endiodimem, to monitor die call for potendal ftandulem uses. 
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Such nioiiitDrii« is ftilly deicriM m the Pnutd System Section of this 
docoment. 

If all the information entered by originating user AA106A is valid 
(decision block YA220) the operation continues in a step YA404 (Fig. 158) 
in which tiie call completion commences. If, on the other hand, aiiy or all of 
the information is found to be invalid, in a step YA222, automated voice 
response unit AB134 informs NCP ABi(M n Che :»11 is transfcrred to an 
MOC. In response, call audio AA142 is routed back to manria switch AB106, 
and NCP AB104 instructs matrix switdi AB106 to route call audio AA142 to 
a manual operator console AB132. This occun in a «ep YA226. This is 
done so tfnt human operator interventkm can be provUed. The steps taken 
from diis point are described beginning in a step YA316 in Fig. 157. This is 
described in detail bdow with rtferenoe to handling of the call with a manual 
operator console AB132. In alternative embodiments, automated VRUAB134 
can provide originating user AA t06A with options (hat oouM potentially assist 
in oorrectiog the stoiation that led to die invalidation. For example, automated 
VRU AB134 may ask a user to enter a new credit card number where the 
originally-entered number was found to be invalkl, or, automated voice 
response unit AB134 may ask a debit card user if diey would like to repleidA 
their debit card usii^ a credit card if such a fesntre is offered. These 
examples serve to illustrate two of the numerous ways VRU AB134 may 
attempt to revalidate the card. 

As discussed above with reference to step YA122 of Fig. 155. if 
manual operator handlii^ is desired, the operukm continues at a step YA304 
in Pig. 157. Referrii^ now to Pig. 157, the human operstor requests 
tnformaticm from a caller and enters die received information via a keyboard 
attached to thtt manual operatOT console AB132. Such information can include 
calling card number, a credit card number, a debit card number, a termlnatii^ 
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(catled) number, and other like information that may be required before the 
call can be completed. 

In a step YA308, operator console AB132 performs validations, where 
required, on card numbers, called numbers, and odier billing information, as 
described above with reference to steps YA202, YA212, and YA216. If die 
validated information checks out to be valid (decision block YA312) the 
operation continues in a step YA404 (illustrated in Fig. 158) in which the call 
is completed. If, on the other hand, one of die validated parameters proves 
to be invalid, die operator informs originating user AA106A of the problem 
and provides options to solve the problem. This occurs in a step YA316. 
These options can include asking the originating user AA106A for a new 
credit card number, a new calling card number, or odier alternative 
information. If alternative information is provided, manual operator console 
ABI32 validates tftis alternative information in a step YA308. This is 
illustrated wiUi a feedback loq> YA342. If no alternatives are provided, the 
call is tenninated as illustrated in a step YA320. 

As discussed above, when all die information is validated, the operator 
console AB108 chosen to handle die call b^ns die process oi call completion. 
This is illustrated in Fig. 158. Referring now to Fig. 158. In a stq> YA404. 
operator console AS 108 informs NCP AB104 diat die call can be completed. 
In one embodiment, diis information has operator response data AB126. 

In a step YA408. NCP AB104 determines die optimum routing for die 
call. In one embodiment, die manner in which diis is performed is described 
in diis document widi reference to Figs. 17 and 21. In diis embodiment, diis 
is accomplished by doing a look-up using DBS BA104 to look-up die opdmum 
routing of die call. 
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In step YA412, NCP AB104 iimnicts matrix switch ABI06 to complete 
the call using the ^lestgnated route, la this step* NCP AB104 sends switch 
control dan AB122 to matrix switch AB106 to instruct matrix switch AB106 
to complete die call. 

5 In a step YA416« matrix switch AB106 routes the call to die 

terminating (called) number as instnicttd in step YA412. 

One feature of call processii^ ^stem AB102 is Uiat it allows users 
AA106 who are subscribers AA 114 of call pracessiog system AB102 to obtain 
10 an enhanced services card. The enhanced services card is a type of calling 

card that allows a user to areess and utlliae any or all of die features diat can 
be provided by call procesring system AB1Q2. Additionally, customer AA 110 
can provide enhanced services cards to its subscribing users AA106. 

A scenario describir^ die manner in which an enhanced services card 
IS call is processed by call processing system AB102 is now described. Rg. 

159, which comprises Pigs. 160 and 161, is an operational flow diagram 
illustrating the manner in which call processir^ sy^m AB1Q2 processes an 
enhanced services card call according to one embodiment. 

Referring now to Pigs. 160 and 161, an origtnadng user AA106A 
20 places an enhanced services card call. This could be accomplished in a 

number of differem ways. In one embodiment, originating user AA106A is 
provided whh an 800 access number by whidi the call can be placed. In this 
embodiment, whenever an originating user AAi06A wishes to phue an 
enhanced services card call, she dials die detignated 800 number. When a call 
2S comes into call processing system AB102 under this nuniber, call prooesting 

system AB102 knows dut it is an enhanced services card call and handles the 
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call accordingly. Inoneembodimem.callprooetaivsyscem ABiOZpfDvito 
an audible menu from which origtrauiiiig uaer AA106A can choose the 
featuie(s) she wishes to access. 

In a step YB104, call processing system AB102 receives an enhanced 
5 services card call. As noted above, this could be via a specific 800 number 

designated foi enhanced services card calls. 

In a step YB108, call data AA144 is routed to NCP AB104, and call 
audio AA142 is routed to matrix switch AB106. When NCP AB104 receives 
call data AA 144 in sttp YBl 12, NCP AB104 determines the type of call being 

10 placed and die processing required. Specifically, in this scenario, NCP ABlOi 

determines that call is an ei^ianoed services card call and performs 
database look-ups to determine the type of call processing required. In this 
step, NCP AB104 determines tfiat an operator console AB108 should be 
dengmted to handle the call. Because responses to menu proroptt and card 

15 numbers can be entered using the telephone keypad, an automated voice 

response unit AB134 is all that is typically required to handle die call. 
Usually, enhanced services card calls do not require a human operator at a 
manual operator console AB132. Thus, in VRU step YBl 12, NCP AB104 
determines that the call can be routed to AB134. 

20 In a step YBl 16, NCP AB104 sends routing information to matrix 

switch AB106, indicating that die call can be routed to the proper VRU 
AB134. This call routing information can include instructions for matrix 
switch AB106as to which specific voice response umt should receive the call 
audb AA142 portion of die call. In response, matrix switch ABI06 routes 

25 call audio AB142 to die designated VRU AB134. After die call is routed, 

NCP AB104 sends operator comrol data AB124 to die designated VRU 
AB134. OperBtt>rcontroldataAB124 includes call information, such as any 
pertinent information retrieved with call parameters BA308. Additionally, 
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openior control dtto AB124 includes <tali tellii^ tlMt VRU ABI34 that it Is 
receiving ft call and how the call should be pnioessed. At this point, the call 
is ooRipkted to the designated VRU AB134. 

In a step YB120, opeiator console AB108 requests requited information 
from originadng user AA106A. This information can be information such as 
the number tmginating user AAIOM wishes to call, the feature she wishes to 
access, calling card information, and any other like information. The 
information requested and the order in which it Is requested can be customized 
as specified by subscriber AA114 and/or a user AA106 of customer AAllO. 
In one embodiment, this customlalion is provided as a fonctton of DBF 
records (described in dw DBF Sectfon of tfiis document) and the call 
pararoeter BA308 data records retrieved during the call ID look-up. 
Originating user AA106A responds lo tMs query by pressing the sppropriate 
keys on the telephone keypad. This can be a setoclion from a menu, or entry 
of die card number* 

In a step YB124, the enhanced servtees card informatkm eitteied by 
originating user AA106A Is validated. In one embodiment, tfiis validation is 
per f or me d by Validation System AOi02. An internal validation may be 
perftmned to determine if enternal validation by Validation System AG 102 is 
necessary. 

If a magnetic card reader is provided at the focation of originating user 
AA 106A, originating user AA106A may not be required to enter her enhanced 
services card infbrmation as tills can be read electronicaily and provided to 
automated VRU AB134. 

In a stq> YB126, if a terminating (called) number is entered, tills 
number is validated to determine tiiat it is a valid number. In otiier words, it 
is validatod to determine whedier It contains die correct number of d^its, die 
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area code is valid, and other like parameien. Call prooesnog system ABI02 
can also perfbnn look-up^ against information in the fraud detection and 
prevention system AG 112 as discussed in the Fraud System Section of rtiis 
document 

S In a step YB202, if originadng user AA106A enters a feature access 

code, this code M validated to determine whedier it is a valid fie^^ 
par^lar eitenoed services card. Additionally, originating user AAI06A 
may be prompted to enter a security code which can then be validated against 
the card number. 

10 In one endndiment, Oe system performs took-ups to determine if 

eidianoed feamres are available to die eitenoed services card number diat is 
beli« used, diat die foature code is a valid access code, and whldi fficature die 
code provides access 10. In one embodiment, die database look-up for feature 
avaiUbility can be done at die time diat die card number is entered as pan of 

15 cant number verification. Enhanced feature availability and access codes can 

be cttstomiied at die cani level based on cani numbers. Sme of die features 
that can be provided Include, but are not limited to, conference callii^, voice 
mail, directory assistance, and information services. Again, diiscustomixation 
is a fonction of the DEP records and the call panmetere BA308 retrieved 

20 during call ID kxA-iqi. 

If any of die information entered by die caller is invalid (deduon block 
YB2a3), automated VRU AB134 gives die caller a second chance to enter 
valid information. If die second attempt foils, die VRU informs NCPABI04 
via operator response data AB126 of such a foiled attempt Indiiscase, NOP 
25 AB104 can provide die call to a manual operator console for additional 

handling. In diis case, die audio portion of die call is transferred back to 
matrix switch ABI06 and dien sem lo die manual operator console ABI32 
based on information provided by NCP ABI04. 
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This second attempt to enter valid infannation and the tnuufer lo the 
manual operator console art options tfiat arc conftgunbte on a per-user 
AA106 basis. The system can be set up so that any number of attempts can 
be permitted before the call is terminated. Additionally, it is not necessary 

S diat the call be sent to a nuuiual operator console AB13Z to retpiest additional 

information from originating user AA106A. This could be p er fo rmed at a 
certain k vl by automated VRU AD134. Also* call pnioesslqg system AB1Q2 
could be set up so that the automated VRU AB134 plays or syndiesiics a 
script asking die caller id call a customer service line, to hang up and try 

10 again, or whatever odier additional instructions may be specified by cusumier 

AAIIO. If the information is validated as indicated by dedsion block YB2^ 
in a step YB204, operator console AB108 informs NCP AB104 diat the call 
can be completed. This informadon is provided via operaior response data 
AB126. 

15 In a step YB204, operator console AB108 infmns NCP AB104 diat the 

call can be ccmipleied. This information is provided in operator response data 
AB126. 

In a step YB208. NCP ABi04 determines die optimum routing to route 
die call ID die terminating (called) number. This can be accomplished by data 

20 look-up as described above widi refenenoe to Figs. 21 and 17. The kiok-iq) 

can be based on die originating number, terminating number, feature access, 
account, and access mediod. Once diis Is done, NCP AB104 sends a con^kle 
call request to matrix switch AB106. The oompleie call request contains all 
die information needed by matrix switth AB106 to generate call data required 

25 to route the call to die correct destinaticm. 

In a step YB212, matrix switch AB106 uses die information provided 
by NCP AB104 to complete die call. The call can be returned to tiie carrier 
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network in thecaseofacustomerAAllO that isac^ or a network of call 
IHOoessiiv system ABIQZ for oompMon. 

Ki any point after call is completed to the deitinatkm number, 
oiiginatiqg user AA 106A m^ press a designated Ic^ (for instance, the D and 
re-originate the call. Reoriglnation takes die caller to the pdm where she 
entered a valkl called mmiberOTtatuie access code, llius, by le^iriginadog, 
originatii^ user AA 106A may place anote call iiidiout having to rt-^om the 
caid billing informadon. This is illustrated by a step YB216. The number of 
times a caller may te^iriginate a call Is configurable. 

/XJ DMCmfiOUt 

Call processing system ABICQ can be used to provide subscriben with 
option of va$SdT% toll calls using debit cards. Call processing system 
ABIOZ can provide debit card calling to originating v<tn AAKMA who 
subscribeiDaprocessiiv system ABlQ2,andtocu8tomeraAA110. Customers 
AAl 10 may m turn offer debit card caltiiv to dkdr subscribing users AA106. 
As discussed previously in dtis documr% ove feature of call processing 
system ABIQ2 is diat it can offer customer AAUO and user AA106 unique 
customizable services. A high level scenario describing die manner in whMi 
debit card calling can be provided by call processli^ system ABICQ is now 
presented. Fig. 162, which comprises Hgs. 163, 164, 165, and 166, is an 
cperatkmal flow diagram illustrating a debit card calling scenario. Referring 
now to Fig. 163, In a step YC104, call processing system AB102 receives a 
call. In one embodiment, die call is made to a de^gnated debit card UO 
number. In diis enMiment, call prooessbv syttem AB102 knows duu the 
call is a debit card call based on die 800 number. In av* aheraadve 
embodlmoit, a 0, or 0+ call is placed. In diis alternative, an opt ra. r console 
AB108 must intervene fio process die debit card call. 
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In a step YC108, call data AAI44 associated with the call is routed to 
NCP AB104. Call audio AA142 of the call is routed to matrix switch AB106. 

In a step YC112, NCP AB104 receives call data AA144 for die call. 
NCP AB104 determines die type of call being placed and the call processing 
required based on call data AA144. In one embodimoit, this is accomplished 
by NCP AB104 performing database look-ups using call data AA144 to search 
for data records. Fcm' example, CMP BA102 retrieves call paran»ters BA308 
from a database served by DBS BA104 and based on the called number (the 
debit card BOQiir), call parameters indicate dtat a debit card call is being placed. 

In a step YCl 16, NCP AB104 sends the routir^ information to matrix 
switch AB106. Because diis is a debit card call, as determined by NCP 
AB104 in step YCl 12, the call routing information includes instructions from 
matrix switch AB106 regarding which operator console AB108 should receive 
call audio AA142 for the call. Thus, call audio AA142 can be routed to the 
proper operator console AB108. It should be noted that because this is a debit 
card call, the operator console AB108 to which die call is routed is prefierably 
a VRU ABI34. In response to dits routing information, nuitrix switch AB106 
routes the call to die deagnated operator console AB108. Because NCP 
AB104 is controlling the call data AB144, and the operator console AB108 
only gets die call audio AB142 pordon of die call from matrix switch AB106» 
operator console AB108 is treated as any odier desdnation. Therefore, die 
specified operator console AB108 can be treated just lilce any odier terminating 
point of matrix switch AB106. Traditionally, such treatmem was limited only 
to odier switches and special ports were required on the oonvemionai matrix 
switch to interfsce to the operator consoles. 

In a step YC120, NCP AB104 sends operator control data AB124 to 
die ^ified operator console AB108. Operator control data AB124 can 
include call ID information diat indicates die type of call and die type of 
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procenii^ reqinred to handle the call. Because call prooessing aystem AB102 
is highly dirta driven, die ^ of call prooesnng piavkled for a cte^ 
can be oustomlaed tbr a specific ori^natiog user AA106A or customer 
AAllO. Chai^ to die way in which a pardcular call Is processed can be 
5 accompiished simply by chaqgiiig die data in die data records retrieved by 

NCP AB104 when deienniidiig die call prooesdng requlreroms. 

Operator control data AB124 tells die specified operator console AB108 
diat it is receiving a debit card call and bow die call diould be processed. 

Because dds is a debit cant call, a VRUAB134U preferred. Itshould 
10 be noted dmt users AA106A or customers AAllO may specify whedier 

auiomatad caU handling is acceptable or v^iedier di^ prefiB^ 
always handled by a human operator at a manual operator console AB132. In 
one enibodiinem, diis is controlled by call paramttrs BAS08 and can be eadly 
be dianged by chai^i« die dam found in data records retrieved for one or 
15 more (ffiginatiog users AA106A or customers AAllO. 

If the call requirss a manual operator console, the operation continues 
in a step YC304 as illustrated in Fig. 165. On die odier hand, if die call can 
be handled using an automated VRU AB134, die opeiation continues in a step 
YC204asilhi8tntBdinFig. 164. The manner in which die callis set up using 

20 an automated VRU AB134 is now described widi itferenoe to Ftg. 164. 

Referring now to Fig. 164. in a step YC204, die specified VRU ABi34 
requests infbrmatkm from originatii^ user AA106A. The request can be a 
request for the number that originating user AAt06A wistes to caU, and/or 
for die dMt card nuiriber, or odm' information required to conqilete die call. 

25 The order In which VRU AB134 requots diis call information can be 

customi»l for eadi carrier AAllO or for each individual user AA106A. The 
customization can be based on call parameters BA308 and/or die manner in 
which DEP records are implemented for eadi originating uaer AA106A or 
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ciutomer AAllO. DBF itoords are oomptetely deicribed In the DEF Sectkm 
of thb docuinenL 

Debit cud infonnation (for example, debit card number, and/or 
aecuricy access code, etc) is sent by automated VRU AB134 to Validation 
5 System AG1Q2 so diat d» infonnation may be validated externally in one 

embodlmem. This oocun in a step YC208. la alleniative embodiments, 
validadm of die debit card information is perfcnrmed tntemal to the call 
processing system AB1Q2. 

In a step YC212, if a terminadng (called) nwnber is enteitd, tfiat 
10 number is validated a> verify that it is a valid number. In one embodiment, 

diis is aooomplidied by usii^ an internal validation icystem to determine 
whedier it is a valid number. A validation check can iidude a check to see 
dot die number contains die correct number of digits, diat Is made to a 
geQgn4>hic area as allowed by die customer AAllO, has a valid area code, 
15 and other like validation information. 

In a Btep YC216, Fraud detecdba and prevendon system AG112 can 
be used in one embodlmem, to monitor die call for pcnendal fiaudulem uses. 
Such monitoring Is folly described in die Fraud System Sectkm of dus 
document Information provided to die Fraud detection and prevention system 
20 AG112 can Include die ANI, die debit card numiier, die called number, and 

odier call information. 

In a step YC218, callii^ dme is calculated based on rating infmmation 
associated widi d» card. If dw card Is flat-iated, die remaining dme is 
calculated agmnst die remaining dollar balance on dK card, if die card rates 
25 are based on call distance and/or dme of day die system obtains a rate quote 

from Billing System AGia2 as discussed above in die Billing System Section 
of dils documem, and calculates the remaining time. Debit card features can 
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be cuttomiaed Cor each cirrier AAUO or for eich individiial uaer AA106A. 
The customiiation can be down CO die cant le^ Debit card calling can be 
based on a flat nte or baaed on mileage and/or time of day In increroents 
specified by subscriber AA114. The custtnniiation can be based on call 
S paiEmetenBA306 and/or die manner in which DBF leooids are ImpleoM^ 

for each originatii« usor AAI06A or customer AAllO. DBF reconb are 
completely described in the DBF Secdon of diis document 

If all the Information enimd by originating user AAIOM is valid 
(dedsiottbloc^YC220)dteopei«don continues in a step YCW 166) in 
10 which die call oonqiletion commences. lf,ondieodierhand«anyoraliofdie 

infonnation is fbund lobe invalid, VRU AB134 may give the caller a 'second 
chance' (0 enter (he correct information* Or the user may be given a chance 
m replenish die del^t card. 

If it is still invalid, in a step YC222, auttmiated VRU AB134 informs 
15 NCP AB104 duit die call is Invalid, in lesponse, call audio AA142 is routed 

back n> matrix switch AB106, and NCP AB104 instructs matrix switdi AB106 
to route call audio AAI42 to a manual operator consote AB132. This occurs 
in a step YC226. This is done so diat human operator intuvention can be 
provided. The stq;» taken from this poim are described beginning in a step 
20 YC316 in Ftg. 165. This is described In detail below witii reference to 

liandliqg of the call widi a manual operator console AB132. in an alternative 
embodiment, die call is not routed to a manual operator console AB132 but is 
instead terminated by VRU AB134. 

As discussed above with reference to step YC122 of Fig. 163, if 
25 manual operator Inndliqg is desired, die operation continues at r step YC304 

in Fig. 165, Referring now to Fig. 165, die human operator requests 
infonnation from the caller and enten die received infornotion via a keyboard 
anached m the manual operator console AB132. Such information can include 
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the debit card number, t terminitiiiK (caiM) number, and other like 
infionnation that may be required befixe die call can be oomptefied. If die 
caller wishes to refilemdi a debit cant, diis informadoo can indude a credit 
cafd number used to pay for vepleniMng die debit cafd. 

In a step ¥€308. opentor otmaole AB137 performs validations, where 
required, on card numbers, called nunters, and odier billiag infonnatiaii, as 
described above with refeicnoe to steps YC2Q2, YC212, and YC216. Manual 
operator console AB132 also computes die calliog time allowed (as per step 
YC218). If die validated informatkmdiecb out ID be valid (dedsloo block 
YC302) and diere is enough time left on die debit card, die opersfitm 
comimies in a step YC404 Ollustrsted in Bg. 166) in wbidi die call is 
oompteted. If, on the other hand, one of the validated parameters prowes lo 
be Invalid , the operator informs origimtii^ user AA 106A of die problem and 
provides options to s6lve die prbblem. This occurs in a step YC316. These 
options can Indude asking the ori^nadi^ user AA106A for a credit card 
number to repleidsh the debit card, ot odier altemative information. If 
ahcmadve information is provided, manual operator oonsiile AB132 validates 
diis altemative tnlmnation in step YC308. Tltis is ilhistitted widi a fieedback 
toQpYC342. If no alternatives are provided, die call is fieiminared by MOC 
AB132 as illustrated In a step YC320. 

If die call is terminated before tt is oompletod, the operator console 
AB108 diat tmiinates die call (VRU ABI34 <v MOC AB132) informs NCP 
AB104 diat die call is terminated ao diat time and chaiBcs against the card are 
not accrued. 

Whedier a second chance is provided and wbedier die call is 
tnmsfierred to an manual operator console AB132 for additional assistance, are 
options diat can be selected by die diem. These options can be customiaed 
to die customer AAllO, user AAI06, or card Icvd. 
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As discussed above, when all the information la validated, the cperalw 
console AB108 chosen to handle Che call begins the process of call completion. 
This Is illustrated in Pig. 165. Referring now to Pig. 166, In a step YC402, 
the opentor console AB108 handling die call infiorms die caller of the calliiig 
S time renudning on the call. 

In a step YG404, operator console AB108 informs NCP ABi04 diat die 
call can be completed. In one embodiment, dtis Information has operator 
response data AB126. 

in a step YC408, NCP ABIM determines die cpdmum roudi^ for die 
10 call. In one embodimem, die manner in whldidiis is performed Is described 

in this document with teferenoe to Pigs. 17 and 21 . In diis enibodimem, ttiis 
is accomplished by doing a look-up using DBS BA104 to look-up die optimum 
roudng of die call. 

In step YC412. NCP ABI04 instructs matrix switch AB106 to complete 
IS die call using die designated route. In dils step, NCP AB104 sends switch 

control data AB122 U) matrix switch A&106 to instruct matrix switch AB106 
to completB the call. 

In a step YC416, matrix switch AB106 routes die call to die 
termlnadr^ (called) number as instructed In step YC412. 

20 In a 8lq> YC418, NCP AB104 monitors die call duration and provides 

warrongs to the caller when die time rennainii^ on die card IS about to expire. 
The manner in which dOs is accomplished is folly discussed above in die 
Billing System Section of diis document 

At any time, originating user AA106A (die caller) may press a 
25 designaied key (for example, die I key) and reoriginate on call processing 
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ssntem AB1Q2. Reorigimtion lakes the caller to the nep of entering a valid 
called number and placing anodier call wiiliout having tti renter the card 
number. The number of dmes a caller may reoriginate Is oonfigiuible and 
customizabkiodieuser AA106,cuftomer AAtlOandcanllevela. The caller 
may be restricted firoi. leor^nadr^ whendieremtiitingdolfaurainoiimoathe 
card teachet aero. 

An additional aervioe provided by call imessing ^ttem ABIOS is the 
ability for a USER AA106 lo |»0gnmi its BOO number to fonmud it (or tt- 
route it) to amxher tdcphone number. This is useftii far a saleqpenon, fbr 
example, who wants customeii to reach her via her 800 numto when Ae is 
travelling away firom die offioe. The sateqwrson oouM access call processing 
system ABKS, enter the 800 number and a securtQf oode« and dien emer die 
number to which she wishes her 800 calls to be fbiwanled. This service is 
denominated *800 On The Go/ 

There are at least two scenarios tfiat may occur in coniuncdon widi 800 
ondmgo. Oitt scenario IS dutt of die USER AA105pn]inmmh|g die mlmber 
to which he wants his calto to fsrward (*800 On die Go* progrsmnd^^ A 
second soeram is die process folhiwed by call prooesrii« system ABIQ2 in 
oonq>ledi« a call pboed to a forwarded 800 mimber. Note diat dus service 
is not Umited to forwarding of 800 numbers, but could be imptemenied to 
forward odier numbers as well. 

A hiflli level scenario itescribing die manner In which a subscrftier 
AA114 te-rouies an 800 number ("800 On The Go" programming) using call 
prooesnng ^stem AB102 is now presemed. Fig. 167, which comprises F«gs. 
168, 169, 170, and mjsanopentttonalfkiwdiagruniUustntdngdieinamier 
in which a subscriber re-routes her 800 number. Ref^ng now to Pig. 167, 
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in a siep YD104, call procesiing system AB102 receives an 800 re-routing 
call. In one erabodimem, Als call is placed to a specific 800 number 
designated for 800 number re-iouting 

In a step YD108, call data AA 144 associated with the call Is routed to 
5 NCP AB104. Call audio AA 142 of the call U routed to matrix switch AB106. 

In a step YD112, NCP AB104 receives call data AA144 for die call. 
NCP AB104 determines die type of call bdng placed and d>e call pmessii^ 
required baaed on call data AA144. In one emboifinient, diis is accomplished 
by NCP ABlOi performii^ database iook^4» usiQg call data AA144 to search 

10 for data records. In diis embodiment, the data records indicate die type of 

processii^ and opemtor services required to handle tbe call. An example of 
diis is where CMP BA102 retrieves call parametera BA308 ftom a database 
served DBS BA 104 and Is discussed indie Network Control Processor Section 
of diis docunwnt. Also, NCP AB104 determines die optimal routing of die 

15 call. Because die temdnating (called) number of this call is die designated 800 

nundier for 800 number re-routing, NCP ABt04 determines tiiat die caller 
needs to interfitte to a VRU AB134 to perform die re-routing. 

In a step YDt 16, NCP AB104 sends die routing information to matrix 
switch AB106. Because tills is an 800 number re-routiqg call, as determined 

20 by NCP AB104 in step YD112, die call routirv information includes 

instructions from matrix switch AB106 regarding whidi operatxn' console 
AB108 should receive call audio AA142 die call. Thus, call audio AA142 
can be routed to die proper operator console AB108. It should be noted dua 
because dds Is an 800 number re-routing call, die preferred operator console 

25 AB108 to whidi die call is routed is a VRU AB134. In response to diis 

routing information, matrix switch AB106 routes die call to die designated 
operator console ABIOS. Because NCP AB1(M is controlling die call data 
ABI44, and die operator console AB108 only gets die call audio AB142 
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portkm of the all from nuurix switch AB106, opentor oomole ABUM is 
treated u tny other destination. Therefore, the qiecified openior console 
AB108 can be treated just like any odier termJnatiQg point of matrix swiidi 
AB106, Traditionally, such treatment was limited only to odier switches and 
special ports were required on the conventional matrix swiich to intcffaoe lo 
the openuor consoles. 

In a step YD120, NCP ABI04 semte opentor control data AB124 to 
the specified qienuor console AB108. Operator oontnri data AB124 can 
include call ID information tfiat indicates die call is an MX) number re-roudng 
call, and the type of processing lequired to handle die adi. Beeauae call 
processii^ system AB1Q2 is highly data driven, the type of call processing 
required for a call type can be customized for a specific originatit^ user 
AA106A or customer AAllO. Oianges to the way in which a particular call 
is processed can be aocomplLdied simply by changing die data in die dam 
recmds retrieved by NCP AB104 when deterauning die call processing 
requirements. 

Operator control data AB124 tdto die i^iecified operator console AB108 
that it is receivii^ a call and how die call should be processed. 

Even diough die preferred handling is provided dinwgh a VRU AB134, 
die call can be handM by ddier a manual operator console AB132 or a VRU 
AB134. Users AA106A or customers AAllO may qiedfywhedier automated 
call handlti^ Is oJfxptsble or whedier diey prefer diat ttieir calls are always 
handled by a human operstor at a manual operator console AB132. In one 
embodiment, diis is contrcriled by call parameters BA308 and can be eaaly be 
changed by changing die data found in data recmls retrkved for one or nMm 
originating users AA106A or customers AAllO, 
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If the user AA106A or custDmr AAllO requested a huiittn operator, 
the operadon ootttiiiues in a step YD304 as illustrated in Pig. 170. On die 
odier hand, if the call can be handled using an automated VRU AB134, the 
opeiadon condnues in a step YD204 as illustnted in Fig. 169. The manner 
in which die call ts set up using an automated VRU AB134 is now described 
with refeience to Pig. 169. 

Referring now to Fig. 169, in a step YD204, the specified VRU 
AB134 requests infDrmadon from originating user AAt06A. The request can 
be a request for the 800 number to be re-routed, a security code, and die 
nunter to whidi it should be routed. The user may be asked to confirm die 
re-route of die number by pressing a specified key (or key sequence) on die 
telephime keypad. The order in which VRU AB134 requests diU call 
informadon can be custtmiiied (br each carrier aA 1 10 or for each indivkiuai 
user AA106A. The customization can be based on call paiametera BA308 
and/ra- die manner In which DBP records are implememed fior each originadng 
user A A 106A or customer AAllO. DEP records are completely described in 
die DEF Section of diis document. 

in a step YD208, die 800 number and die securi^ code entered by die 
caller are sent to be validated. In one embodiment, this validadon is 
performed usit^ a tnuuladon database ZA106 (illustnued in Pig. 207). In 
altemadve embodiments, validation can be performed internally in eoiyuncdon 
with calllD look-up. Additional intbrmatlon entered }iy die caller is also 
validated in diis step. An internal validation qrstem determines if vaikfaulon 
by Validadon System AG 102 is required. If such validation is required, it is 
performed as well. 

In a step YD212, die termlnadng number to which die 800 number is 
tu be re-routed is validated to verify diat it is a valid nundier. In one 
embodiment, diis Is accomplished by using an internal validation system to 
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determine whetfier it is a valid number. A validation check can include a 
check to see that the nunter contains the coma number of digits, tfiat is 
made to a geographic area as allowed by the customer AAllO, has a valid 
area code, and odier like validation information. 

5 In a step YD216, Frsud detection and prevention system AG112 can 

be used in one embodiment, to monitor die call for poiendal fruidutent uses. 
Sudi moniiDrii^ is fiiUy described in the Fraud System Section of this 
document 

Inastep YD218, die number to which the 800 number sbouki route is 
10 replayedanddiecaller is requested Impress a key (or key sequence) to accept 

the re-roudng. If dw change is accepted, a call prooessiqg database is updated 
widi die new number. 

If ail the informalion entered by originating user AA106A is valid 
(decision block YD220) tiie operation condnues in a step YD404 (Fig. 171) 

15 in which the call oompl^ion commences. If, on die oUier hand, any or all of 

die informadon is found to be invalM, in a step YD222, automated VRU 
Afii34 informs NCP AB104 diat dw call is invalM and gives die calln a 
second chance to re-enter die information. The informadon is again validated 
as iUustrated by feedbadc loop YD262. Altemadvely, die call could be 

20 terminated when informadon is found to be invalid ddier before or after die 

second chance is provkled. The number of chances, if any, provided to a 
caller is customizable on a per user AA106 or per customer AAllO bans. 

If die caller dedmes to le-enter die informadon, <n- if die second 
chance is already exhausted, call audio AAI42 is routed bade to matrix switch 
2S AB106, and NCP AB104 instrucu matrix switdi AB106 to route call audio 

AA142 to a manual operator console AB132. This occurs in a step YD226. 
This is done so that human operttor intervention can be provided. The steps 
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taken from this pdm are described beginning in a step YD316 in Fig. 170. 
This is described in detail below with lefmnce to handling of the call with a 
manual operator console AB132. 

As discussed above with reference to step YD122 of Fig. 168» if 
manual operatxH' handling Is desired, die operation continues at a step YD304 
In Hg. 170. Refcrriag now to Fig. 170, die human operator requests 
Information from a caller and enlera the received Information via a keyboard 
aoached n> the manual operator console AB132. The request can be a request 
for the 800 number to be re-routed, a security code, and the mimber to which 
it shouM be routed. The user may be asked to confinn die re-route of the 
number. The operator is prompted to make die request by prompu appearing 
on die operator screen. The order in whteh dih call infbrnudon is requested 
can be customheed for each carrier AAllO or for each individual user 
AA106A. The customization can be baaed on call paramete|fs BA308 and/or 
die manner in which DBF records are implemented for each originatii^ user 
AA106A or customer AAUO. DBF records are compietely described in die 
DBF sectitm of diis document. 

In a stq> YD308, operator console AB132 perfbrms validations, where 
requited, as deKribed above witii reference to steps YD208, YD212» and 
YD216. Operator console AB132 may also ask for confirmation of die 
nuinber to which die 800 number u to be re-routed. If die valklafied 
information checks out to be valid (decisitm block YD312) die operation 
continues in a step YM04 (illustrated in Fig. 171) in which die call is 
completed. If* on the odier hand, one of die validated parameten proves to 
be invalM, die operator infbrms originating user AA106A of die problem and 
provides options to solve die problem. Thisoocuninastep YD316. These 
options can include asking die originating user AA106A for a new security 
code, a new re-route number, or odier alternative information. If alternative 
information is provided, manual operator console AB132 validates dits 
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alleniative tntbrmatioii in a siqi YD308. Thli \% Uluttnted with a Mbmk 
loop YD342. If no iltematives arc provided, or die caller dedinei to fumtih 
the infDnnation» die call it termlnaied as illustiated in a itq» YD320. 

When al( n formation is entered and validated, the 800 number can be 
programmed to re-route. This is illustiated in P(g. 171. Referring now to 
Fig. 171 , in a step YD404, operator console AB108 infonns NCP AB104 diat 
die 800 number is to be le-routed when called. In one embodimem, this 
informadon has operator response data AB126. 

In a step YD408, NCP updates a master call prooessiiv database . 

In step YD412, Distribudon System HAIOO (illustnted in Fig. 93) 
updates die affected Slave Databases HAllO. 

In a Step YD4I6, die caller is informed diat die re-roudiig iscompleied 
and all calls on diat 800 number will be forwarded to die designated number 
when received. If die change is made using a VRU AB134, die information 
is provided by taped or symhesized voice. If made by a human operator at a 
MOC AB132, a script is read from die operator screen. 

In a step YD418, die call is termlntted. 

A high level scenario descril»i« die mannerin whidi a direct-dial kn^- 
distanoe call is processed by call processing system AB102 Is now tnesemed. 
Rg. 172, isanoperatioittlflowdiagiamillustiadngdieplacememofatfiTect- 
dial kmg-distanoe call. Referrit« now to Rg. 172« in a step YEt04« call 
processii^ system AB102 receives a direct-dial lot«*distanoe call (for example 
a 1-1- call). In a step YE108, call data AA144 associated widi die call is 
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routed to NCP ABIM. Odt audio AA142 of die call is nmted to matrix 
switch AB106. 

In a step YEl 12, NCP AB104 asdgnt a callhandle BA3QS to idendfy 
die call. Callhaiidle UXS is a unique number used to Idemify die call at 
each phase of processit^ widiln call processing system AB102. Callhandle 
BA305 Is also used to Idendfy die call for billing puipoaes. 

In a step YEl 16« NCP AB104 detennines the type of processing to be 
provided to die call. Thistsaocom|riishedbydetenniningdiecallpaiameten 
BASOgfiBTdiecaU. 

Ina Step YB120, dK call is valtdated to delenniiK whedier it should 
beomipleied. One paiameter diat may be validalBd for die call is die called 
number. The validation check can include a check to see ditt the nmber 
contains die correct number of digits, diat is made to a geographic area as 
allowed by die customer AAllO, has a valid area code, and odier like 
validation information. 

In a step YE124. if die call is valid, it is completed to die destination. 
This Is aooonqillshed as described above widi reference to steps YA408 
dirough YA416inF^. I7L If die call is invalid, it can eidier be terminated, 
or die audio AA142 routed to an openttor console AB108 to inform die user 
AA106 dwt die call cannot be completed* The manner in which die call is 
routed to opeiator console AB108 is described above with reference to steps 
YA1I6ID YA122inFig. 155. 
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13.0 OtmmiorCo9uoUDi^ki(9 

When a call is routed to a MOC AB132, informaiton derived from 
operator contnri data AB124 is dlq»iayed cm an opeiator display scieen. A*: 
example implememation of an opeFStor display scieen is now described. Hg. 

S 2QS is a diagvam illustiating an exan^le impleroematitMi of an opeiaior diqilay 

screen. Referrii« now to FIG. 2QS, in one embodiment an opeottM' disiilay 
screen VAIOO conqirises five key areas. A script portion VAICS is the 
portion of the screen in which a scr^ sppean that is read by the opentor 
when sn^>V or addressiitg the caller. An orfgittation portion VA104 is a 

10 portion of die scieen in which infbrraatlon about die origin of die call ii 

dispteyed. A terminad<Mi portion VA108 is a porticm of die screen in which 
information about die termination (actual or desired) of die call is dispfaqwd. 
An infidrmation portion VA106 of die screen displays information about die 
call and the call type. Finally, a function key pcmkm VAIU di^hiys 

15 information about die fitncticHis performed when a particular function key is 

pressed. 

An exanqile of display screen VAIOO widi call ^nfbrmadoo is now 
described. Fig. 206 is a diagram illustrating an example of display screen 
VAIOO widi call informadon tUsplayed dieitoo. Referrii^ now to Fig. 206. 

20 script portion VA1Q2 dispkys die 8cri(tt ID be read to die user AA106A. In 

diis example die script / ha^e ikt ores cocte and iiwister yarn are 
€alBnif*\%^\as^m\iM\stTeiAbit^ap^^ The script displayed 
u dq>eiktem upon die call type aiid at what stag^ die call is In call pnioesa^^ 
As described in die DEF Section of dus spplicatioD, one mednd uBd to 

2S determine die script to be dUphyed (and dierefore read) Is 1^ udng piooesaes 

TA102. TA106, and DEF records TA104. 
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Itm ofigtnatioii portkm VA1(M in this exae^le indicates that the 
dunttooof thecilliq»tDlheairiemtiinei8 208eo^ In one embodimem, 
the duistion Indites onoe per aeoond. The local droe at the origination point 
is 7:22K)1. The time is also updated once pet aeoond in one embodiment 
Also lUsplayed on the origination portion VA104 li die origination user's 
name, aiea code and phone number, and civ and stale. If the originating user 
AA106A is a dient of a custoir^, that information Is dispfa^yed in die fletd 
deiignatBd "carder.* 

The call infomratim portion VA106 in dds example includes a call 
type, a billing nuniber, and a called number. In this case, die call type is a 
UnicUSA enhaiued services card (ESQ. Because in tlds example die user 
dialed the BSC number, no called number appears on die screen. 

When a call is completed, the termination portion displays dw 
termimdiv user's name, area code and phone number, and city and state. 
The termination portion VA108 also includes die call duration from the time 
the call was completed and the completion time. 
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14. Comduslam 

While various embodimemi of the preaent invendoo have been 
described above, it ihould be understood that they have been iNT^^ 
of example only, and not limitation. Thus, the breadth and aoope of the 
pment invention should not be limited 1^ any of the above-described 
exemptaiy embodiments, but dmld be defined only in aooonbnoe witti die 
fbilowing dafans and dieir equivalents. 

It should be noted ±*t die block diagnms depided duoiQliout diis 
docimiem illuatiato an example of how the fiincdonali9 of die varioos qrste^ 
can be imptemaated. Ahhough phyrical or logical ai ch U pc tui es may be 
inferred by die diagnms and die text deaciibli« diese dfatgnms, it is i 
to note diat diis is done by way of example only. Numenws aheraadve 
phyrical and/or logical aichltectures can be chosen when implonendng die 
systems described herein. 
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K A call prooessiiv system, oomprisiiig: 
t switch; 

a network oontiol prooossor oon^Kisiqg 

a flcsc gateway oonpled to said switch, 
a centnl message processor coupled to said first gateway, 
a datahase server and aasndayed dandMse coupled to said 
oenual message prooessort 

a billing server coupled to said central message processor, and 
a call route distributor, coupled to said central messi^ 
procenor; 

an operator console, coupled to said network control processor, 
a validatMM system, ooufrfed to sakl network ctmtrol processor; 
a billing system, cxmpkd to sidd netwoik control processor; and 
a fraud system, coupled to sakl network control processor. 

2. The call processing sytfem of claim 1, further comprising: 
an enor box, ooq>led to said network control processor; and 
a tog box, coupled saki network control processor. 



3. A computer-based system for processing telephone palls 
con^ridng* 

a switch configured to accept call audio for die call and to route 
aaU call audio to a destination to complete a call; 
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a netwofk ocmtnrt piooesw, oou|M CO siM switch 
to accept call data for die call, to uie laU call data to determine how 
UK calMs to be processed, and id configure said switch to louie die 
call to said destination. 

4. The oompiiter4»Bsed system of claim 3, furdierooinprising at 
least one operstor console, coupled to said switch and to s^d neiwoik omttnil 
processor, oonfigurBd to provide operator services to the call. 

5. The conqwter-based system ofdaira 4, wherein said at least ocie 
operator console is an automated operstor console. 

6. The conqimter-based system of dalm 3, wherein sud network 
comn>lpnx:essor comprises a oentnJ message processor, configured to receive 
call data Iran a subscriber, to determine call paruneters for the call based on 
said call data, wherein said call parameteia are used to determine how the call 
is to be proc es se d . 

7. The conqNiter-based system of claim 4, wherein said network 
control processor ooinprises a central inessage processor, configured to receive 
call data from a subacriber, to deiermiiK call panmeteta for die call based on 
said call data, wherein said call paiameten are used to determine wh«her 
operstor assistance is required and how die call is to be processed. 

8. The computer-based system of dam 7, fuidier omiprising t call 
route distribotor, coupled to s»d cemni message processor for attocadng an 
operator console to provkle operator asnstanoe to a call. 
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9. The omnputer-butd system of claim 7, further comprising a 
database server coupled to said central message processor and oonflgured to 
store said call parameters In at least one database. 

10. The coiiq>uter-based system of claim 3, further comprising a 
gateway coupled to said network control processor and configuitd to perfDrm 
communkadons protocol conversions necessary (or communications between 
said network control processor and said switch. 

11. The computer-based lystem of claim 3, f^irther compriung a 
billing ifystem, coupled to said networic comrol processor and conf^ured to 
detemdne a i«te fbr a call and to determine a cost of acalt based on saM rate. 

12. The computer-based system of chdm 4« farther comprising a 
validatkm system, coupled to said network control processor and configured 
validate call information received from said opeiator console. 

13. Theoomputer-based system of daim 12, wherein said validation 
syfiem comprises; 

a i^code database, configured to store at least one validation 
instruction indicating a mediod far performing a particular validaticm, 
wherein said method can be uniquely defined for each customer and 
each originating user; and 

a validator configured to receive die call information to be 
validatBd from an opeiitor console, to retrieve said at least one 
validation instruction fran said p-cocfe dattbase, and to validate die 
call i.iformation using said mediod indicated by said validation 
instruction. 
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14. The oompuier-based tyitem of claim 3« further oomprinqg • 
fnud syitem fm detecdqg pouible oocunenoes of fnudideiit uie of ■ callii^ 
network, coupled to nid network comml procetm and ooofigured lo monitor 
calli, sttne data conoemiag md calls, compare sakt itond data lo preset 
bounds, and trigger an abrro if said stored data b outside of said preset 
bounds. 



15. A call processiQg system for processing and routiqg a telephone 
call, comprisiiv: 

a netwcnk oontnd pnocesscH' oonfigurBd to accept call data far 
the call, to use aakl call data to detmntne how die call is to be 
processed, and to generate inscnicdons regardlt^ roudog of the call: 
and 

a switch, coiq>led id nU network controi pmam^ confvgured 
to accept call audio and to route said call audb to a desdnadon to 
complete die call based <m said instnictkms. 

16. The call processing system of claim IS. wherein said network 
coiaiol processor fMher comprises: 

first means recdvii^ call data from a sidMcriber, 

second means, ooq>led to said first means, for determinii^ a 
call tfft for die call and further d^ennimng whedier die call requires 
operator assistance based on saki call data; and 
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durd means, coupled to aid Hcond meaitt, fior aUocatiog an 
QpefatDT console id handle the call where opeiator assismnoe Is 
required as determined by laid second means. 

17. The call processing system of elaim 16, wherein said network 
control processor further comprises fourth means, coupled to said 
aeoond means, for determining a type of opeiator assismnpn reqidied where 
the call requires operator assistance, wherein said fiourth meaia makes said 
d et ermin a tion baaed on said call data. 

18. The call pnooessiQg system of claim 16, wherein said n^work 
control processor fbnher comprises fourch means, coupled to said second 
means, for asslgidqg an identifier to the call used to identify the call within the 
call processii^ system 

19. The call processiiv system of daim 16, wheran said second 
means comprises means for determlniiig call parameters based on said call 
data, wherein said call parameters Indicate the of processing required for 
the call and whether and what type of operator assistBnoe Is required. 

20. K method of routing telephone calls received from a subscriber, 
the calls having call data and call audio associated therewith, comprising the 
steps of: 

(a) receiving the call data at a networic control processor; 

(b) receiving the call audio at a matrix swttcb; 

(c) determining call paruneiers based on the call dam, wherein said 
call parameters uniquely define the type of processing requtred 
for each received call; 
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